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© A data processing system, method and program are disclosed, for managing a public key cryptographic 
system. The method includes the steps of generating a first public key and a first private key as a first pair in 
the data processing system, for use with a first public key algorithm and further generating a second public key 
and a second private key as a second pair in the data processing system, for use with a second public key 
algorithm. The method then continues by assigning a private control vector for the first private key and the 
second private key in the data processing system, for defining permitted uses for the first and second private 
keys. Then the method continues by forming a private key record which includes the first private key and the 
second private key in the data processing system, and encrypting the private key record under a first master 
key expression which is a function of the private control vector. The method then forms a private key token 
which includes the private control vector and the private key record, and stores the private key token in the data 
processing system. 

At a later time, the method receives a first key use request in the data processing system, requiring the first 
public key algorithm. In response to this, the method continues by accessing the private key token in the data 
processing system and checking the private control vector to determine if the private key record contains a key 
having permitted uses which will satisfy the first request. The method then decrypts the private key record under 
the first master key expression in the data processing system and extracts the first private key from the private 
key record. The method selects the first public key algorithm in the data processing system for the first key use 
request and executes the first public key algorithm in the data processing system using the first private key to 
perform a cryptographic operation to satisfy the first key use request. 
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BACKGROUND OF THE INVENTION 

The invention disclosed broadly relates to data processing systems and methods and more particularly 
relates to cryptographic systems and methods for use in data processing systems to enhance security. 
5 The following co-pending patent applications are related to this invention and are incorporated herein by 
reference: 

B. Brachtl, et al., "Controlled Use of Cryptographic Keys Via Generating Stations Established Control 
Values;" USP 4,850,017, issued July 18, 1989, assigned to IBM Corporation and incorporated herein by 
reference. 

w S. M. Matyas, et al., "Secure Management of Keys Using Control Vectors," USP 4,941,176, issued July 
10, 1990, assigned to IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Data Cryptography Operations Using Control Vectors," USP 4,91 8,728; issued 
April 17, 1990, assigned to IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Personal Identification Number Processing Using Control Vectors," USP 
is 4,924,514, issued May 8, 1990, assigned to IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Secure Management of Keys Using Extended Control Vectors," USP 4,924,515, 
issued May 8, 1990, assigned to IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Secure Management of Keys Using Control Vectors with Multi-Path Checking," 
US serial number 07/596,637, filed October 12, 1990, assigned to IBM Corporation and incorporated here 
20 by reference. 

S. M. Matyas, et al., "Secure Cryptographic Operations Using Alternate Modes of Control Vector 
Enforcement," US serial number 07/574,012, filed August 22, 1990, assigned to IBM Corporation and 
incorporated here by reference. 

S. M. Matyas, et al., "Secure Key Management Using Programmable Control Vector Checking," USP 
25 5,007,089, issued April 9, 1991, assigned to IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Secure Key Management Using Control Vector Translation," USP 4,993,069 
issued Feb. 12, 1991, assigned to IBM Corporation and incorporated herein by reference. 

B. Brachtl, et al., "Data Authentication Using Modification Detection Codes Based on a Public One Way 
Encryption Function," USP 4,908,861, issued March 13, 1990, assigned to IBM Corporation and incor- 
30 porated herein by reference. 

D. Abraham, et al., "Smart Card Having External Programming Capability and Method of Making 
Same," US serial number 004,501, filed January 19, 1987, assigned to IBM Corporation and incorporated 
herein by reference. 

S. M. Matyas, "Technique for Reducing RSA Crypto Variable Storage", USP 4,736,423, issued Apr. 5, 

35 1988, assigned to IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "Method and Apparatus for Controlling the Use of a Public Key, Based on the 
Level of Import Integrity for the Key," US serial number 07/602,989, filed October 24, 1990, assigned to 
IBM Corporation and incorporated herein by reference. 

S. M. Matyas, et al., "A Hybrid Public Key Algorithm/Data Encryption Algorithm Key Distribution Method 

40 Based on Control Vectors," US serial number 07/748,407, filed August 22, 1991, assigned to IBM 
Corporation and incorporated herein by reference. 

S. M. Matyas et al., "Generating Public and Private Key Pairs Using a Passphrase," filed on the same 
day as the instant application, US serial number 07/766,533, filed actually September 27, 1991, assigned to 
IBM Corporation and incorporated herein by reference. 

45 The cryptographic architecture described in the cited patents by S. M. Matyas, et al. is based on 
associating with a cryptographic key, a control vector which provides the authorization for the uses of the 
key intended by the originator of the key. The cryptographic architecture described in the cited patents by 
S. M. Matyas, et al. is based on the Data Encryption Algorithm (DEA), see American National Standard 
X3.92-1981, Data Encryption Algorithm, American National Standards Institute, New York (December 31, 

so 1981), whereas the present invention is based on both a secret key algorithm, such as the DEA, and a 
public key algorithm. Various key management functions, data cryptography functions, and other data 
processing functions are possible using control vectors, in accordance with the invention. A system 
administrator can exercise flexibility in the implementation of his security policy by selecting appropriate 
control vectors in accordance with the invention. A cryptographic facility (CF) in the cryptographic 

55 architecture is described in the above cited patents by S. M. Matyas, et al. The CF is an instruction 
processor for a set of cryptographic instructions, implementing encryption methods and key generation 
methods. A memory in the cryptographic facility stores a set of internal cryptographic variables. Each 
cryptographic instruction is described in terms of a sequence of processing steps required to transform a 
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!fi°I. inPU LT m f J° 3 S6t ° f ° Utput P arameters - A cryptographic facility application program (CFAP) is 
also described in the referenced patents and patent applications, which defines an invocation method as a 
caning sequence, for each cryptographic instruction consisting of an instruction mnemonic and an address 
with corresponding input and output parameters. 

•JOaHl ?a rT i0n a, f rithmS "* deSC " bed in a paper by W " Diffie and M - e - Halman entitled 
m f Authentication: An Introduction to Cryptography." Proceedings of the IEEE, Volume 67 No 3 

IELi I PP ' 1 : Publi ° k8y SySt6mS are based on dis Pensing with the secret key distribution 
channel, as long as the channel has a sufficient level of integrity. In a public key cryptographic system two 
keys are used one for enciphering and one for deciphering. Public key algorithm systems are designed so 
that it is easy to generate a random pair of inverse keys PU for enciphering and PR for deciphering and it is 
easy to operate with PU and PR, but is computationally infeasible to compute PR from PU fach u iser 
generates a pair of inverse transforms, PU and PR. He keeps the deciphering transformation PR seereVand 
makes the enciphering transformation PU public by placing it in a public directory. Anyone can now encrypt 
messages and send them to the user, but no one else can decipher messages intended for him It is 
possible, and often desirable, to encipher with PU and decipher with PR. For this reason, PU is usually 

SHI • Ub H C " P ? iS USUa " y Ca " ed 3 Private k6y - A corol,ary feature of Public key cryptographic 
systems .s the provision of a digital signature which uniquely identifies the sender of a message If user A 
wishes to send a signed message M to user B, he operates on it with his private key PR to produce the 

his ""iTohp 396 " *L US6d » A ' S deCiPherin9 k6y Wh6n Pfivacy was desired ' but ■ is "™ »* as 

« Z TZ ZVT T*?. US6r B reCeiV6S the meSSa9e S - he can recover mes ^ge M by operating 
on the cphertext S with A's public PU. By successfully decrypting A's message, the receiver B has 
conclusive proof it came from the sender A. Examples of public key cryptography are provided in the 
*;: 9 . "J' Patents: USP 4 ' 218 - 582 10 Hel "™. * al.. "Public Key Cryptographic Apparatus and 
Method;" USP 4.200.770 to Hellman, et al.. "Cryptographic Apparatus and Meld; " and USp JiT L to 
25 Rivest, et al., Cryptographic Communications System and Method " 

with HH Cn ; pt09raphic systems make use of ™ny different types of keys, so that information encrypted 

of Thi iZlr™ 3ffe f d b l USin9 3 k6y ° f typa A key is a ^ °n tne basis 

of the information the key encrypts or the use being made of the key. For example, a data- encrypting key 

encrypts date A key-encrypting key encrypts keys. A PIN-encrypting key encrypts personal identification 

numbers (PINs) used in electronic funds transfer and point-of-sale applications A MAC key Tused to 

generate and authenticate message authentication codes (MACs). 

™ m L he US !- ° f enCryp,i ° n is 0388(1 on a strate 9y of Protecting a large amount of information (a data file or 
communications session) with a smaller additional amount of information (a single key). Sophisticated key 

S l \ ' Z u 319 baS6d °" 3 symmetric ke V a '90rithm such as the Data Encryption Algorithm 
2' T ? T 3 T h,efarChy Wher8in teyS be,0n9in9 t0 a ^Ptographic device are encrypted with a 
single master key and stored in a key data set. The master key is stored in clear form within the 
cryptograph.c hardware The concept of using a single master key to encrypt keys stored in a key data set 
is known as the master key concept (see C.H. Meyer and S.M. Matyas, Cryptography-A New Dimension in 
Computer Data Security, John Wiley & Sons. Inc.. New York. 1982.). Until nl.U master tey concept has 
STLSU? ♦ ^Ptographic systems based on a symmetric key cryptographic algorithm. However, 

T " eXtendS ^ maSter k8y C0 " Cept 3nd teaCnes now il ma V be applied to cryptographic 
systems based on an asymmetric key cryptographic algorithm, and more particularly how it may be applied 

LSTn incorporatin 9 asymmetric and symmetric key cryptographic algorithms, 

generally called hybnd cryptographic systems. The reader will appreciate that in a public key based 
cryptographic system employing (1) an asymmetric algorithm or (2) both asymmetric and symmetric 

KltSi 8 ? ,s h a need 5 use many public and private keys pairs - Hence - at a ^ Se 

keys must be stored in encrypted form outside the cryptographic hardware. 

h Jl™**. ? r A Cryp,0 ? ra P hic system employing the master key concept to be made operable, each 

svZT '7 ba,,2ed ^ 3 maSt6r k6y and ° ne ° r m0re other keys t0 tne cryptographic 

system to communicate cryptographically with other cryptographic systems or to distribute keys to other 

1T^Z P T te ™> TyPiCa " y ' 1,1956 k6yS are 9enerated and ins,al,ed usi "9 manual entry techniques. In 

T /TT aPhiC Sy$tem ' a " ° ther k6yS m 9enera,ed and nandled ^ the cryptographic 
system automatically. Keys generated by the cryptographic system are stored in encrypted form In a 

2?^ data 861 ^transmitted in encrypted form to a designated receiving device where the key 
is imported (i.e.. reencrypted to a form suitable for storage and use at the receiving device) Thus an 

ZZS^yV^ SCh6me fe ^ m6th0d ,0 ^ kayS ' 0r Safe a 
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At the time a key is generated, the user or user application determines, from among the range of 
options permitted by the key management, the form of each generated key. For example, a generated key 
can be produced (1) in clear form, (2) in encrypted form suitable for storage in a cryptographic key data 
set, or (3) in encrypted form suitable for distribution to a designated receiving device. Generally, 

5 cryptographic systems have different options for generating keys in these different forms. Also, at the time 
a key is generated, the user or user application determines, from among the range of options permitted by 
the key management, the type and usage of each generated key. Type and usage information are 
examples of a class of key-related information called control information. For example, in US Patents 
4,850,017, 4,941,176, 4,918,728, 4,924,514, 4,924,515, and 5,007,089, and IBM dockets MA9-88-033 (EP 

io application no. 90105905.5) and BT9-90-018 (EP application no. 91109953.9) the control information is 
embodied within a data variable called the control vector. The control vector concepts taught in these US 
Patents and IBM dockets is summarized in a paper by S. M. Matyas entitled "Key handling with control 
vectors," IBM Systems Journal, Volume 30, No. 2, 1991, pp. 151-174. 

In a cryptographic system employing control vectors, every key K has an associated control vector C. 

75 Thus, K and C denote a 2-tuple, where K initializes the cryptographic algorithm by selecting an enciphering 
transformation and C initializes the cryptographic hardware by selecting a set of cryptographic instructions, 
modes, and usage that K is granted. Implementation of the control vector concept requires that K and C be 
coupled cryptographically. Otherwise, the key-usage attributes granted to K by C could be changed by 
merely replacing C with another control vector. The method for accomplishing this is based on integrating C 

20 into the functions used to encrypt and decrypt keys, called control vector encryption (CVE) and control 
vector decryption (CVD). Fig. 1 is a block diagram illustration showing the implementation of the CVE and 
CVD algorithms within a cryptographic facility 30. CF 30 contains a CVE algorithm 1, a CVD algorithm 2, a 
master key (KM) 3, a to-be-encrypted key K 4, and a recovered key K 5. The CVE algorithm 1 encrypts a 
clear key K 4 within CF 30 using a variant key KM + C formed as the Exclusive OR product of master key 

25 KM 3 stored within CF 30 and control vector C 6 specified as an input to CF 30 to produce an output 
encrypted key value of the form e*KM + C(K) 7. Note that " + " denotes the Exclusive OR operation and e* 
denotes encryption with a 128-bit key. The operation of encryption consists of encrypting K with the 
leftmost 64 bits of KM + C then decrypting the result with the rightmost 64 bits of KM + C and then 
encrypting that result with the leftmost 64 bits of KM + C. The CVD algorithm 2 decrypts the encrypted key 

30 e*KM + C(K) 9 specified as an input to CF 30 with the variant key KM + C formed as the Exclusive-OR 
product of master key KM 3 stored within CF 30 and control vector C 8 specified as an input to CF 30 to 
produce an output clear key K 5. The operation of decryption consists of decrypting e*KM + C(K) with the 
leftmost 64 bit of KM + C then encrypting the result with the rightmost 64 bits of KM + C and then decrypting 
that result with the leftmost 64 bits of KM + C. The CVE algorithm is used to encrypt and protect keys 

35 stored outside the CF. The CVD algorithm is used to decrypt and recover keys to be processed within the 
CF. 

Fig. 2 is a block diagram illustration of the control vector encryption (CVE) algorithm. Referring to Fig. 

2, C is an input control vector whose length is a multiple of 64 bits; KK is a 128-bit key-encrypting key 
consisting of a leftmost 64-bit part KKL and a rightmost 64-bit part KKR, i.e., KK = (KKL,KKR); K is a 64-bit 

40 key or the leftmost or rightmost 64-bit part of a 128-bit key to be encrypted. The specification of KK is 
meant to be very general. For example, KK can be the master key KM, or some other key-encrypting key. 
The inputs are processed as follows. Control vector C is operated on by hashing algorithm ha, described 
below, to produce the 128-bit output hash vector H. H is Exclusive-ORed with KK to produce 128-bit output 
KK + H. Finally, K is encrypted with KK + H to produce output e*KK + H(K), where e* indicates encryption with 

45 128-bit key KK + H using an encryption-decryption- encryption (e-d-e) algorithm as defined in ANSI 
Standard X9.17-1985 entitled "American National Standard for Financial Institution Key Management 
(Whole- sale)", 1985, and in ISO Standard 8732 entitled "Banking-Key Management (Wholesale)", 1988. 
Fig. 3 is a block diagram illustration of the control vector decryption (CVD) algorithm. Referring to Fig. 

3, C is an input control vector whose length is a multiple of 64 bits; KK is a 128-bit key-encrypting key 
so consisting of a leftmost 64-bit part KKL and a rightmost 64-bit part KKR, i.e., KK = (KKL.KKR); e*KK + H(K) is 

the encrypted key to be decrypted. Control vector C is operated on by hashing algorithm ha, described 
below, to produce the 128-bit output hash vector H. H is Exclusive-ORed with KK to produce 128-bit output 
KK + H. Finally, e*KK + H(K) is decrypted with KK + H using a decryption- encryption-decryption (d-e-d) 
algorithm to produce output K. The d-e-d algorithm is just the inverse of the e-d-e algorithm. 
55 Fig. 4 is a block diagram illustration of hashing algorithm ha. Hashing algorithm ha operates on input 
control vector C (whose length is a multiple of 64 bits) to produce a 128-bit output H, where H = ha(C). If C 
is 64 bits, ha(C) is set equal to (C,C), where the comma denotes concatenation, and the extension field (bits 
45,46) in ha(C) is set equal to B'00\ That is, ha acts like a concatenation function. If C is 128 bits, ha(C) is 
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set equal to C, and the extension field in ha(C) is set equal to B'01\ That is, ha acts like an identity 
function. If C is greater than 128 bits, ha(C) is set equal to a 128-bit one way cryptographic function of C, 
e.g. a 128-bit modification detection code calculated by the MDC-2 algorithm in Fig. 5, and the extension 
field in ha(C) is set equal to B*10\ In each of the three cases, the eighth bit of each byte in ha(C) is 

5 adjusted such that each byte has even parity. This adjustment ensures that when ha(C) is exclusive-ORed 
with KK, the variant key KK + h(C) has the same parity as KK. The extension field in ha(C) serves to ensure, 
for a fixed KK, that the set of keys of the form KK + h(C) consists of three disjoint subsets S1, S2, and S3! 
where S1 denotes the keys resulting from all 64-bit control vectors, S2 denotes the keys resulting from all 
128-bit control vectors, and S3 denotes the keys resulting from all control vectors larger than 128 bits. This 

w prevents a form of cheating wherein the CVD algorithm is tricked into decrypting an encrypted key using a 
false control vector. Hashing algorithm ha fulfills two important objectives. First, it handles both short and 
long control vectors, thus ensuring that a key-management scheme based on the control vector concept is 
openended. Second, the processing overhead to handle short control vectors (64 and 128 bits) is minimized 
so as to have minimal impact on the key management scheme. 

75 As an alternate embodiment, the length of the input control vector to the hashing algorithm ha can be 
encoded in the extension field (bits 45,46). If the input control vector is 64 bits long, the field is BW, if the 
input control vector is 128 bits long, the field is set to B'0V and if the input control vector is longer than 128 
bits, the field is set to B'lO'. This has the advantage of simplifying the hashing algorithm ha so that it does 
not need to set the extension field in the resulting output H, except if the input control vector was greater 

20 than 128 bits. 

Fig. 5 is a block diagram illustration of a cryptographic function for calculating a 128-bit modification 
detection code (MDC), called the MDC-2 algorithm. Referring to Fig. 5, K1 = X'5252525252525252' and 
L1 =X , 2525252525252525' are two 64-bit nonsecret constant keys. They are used only to process the first 
64-bit block of plaintext, Y1. Thereafter, input value K2, K3, .... etc. are based on output values (A1,D1), 

25 (A2.D2), etc., and input values L2, L3 etc. are based on output values (C1,B1), (C2,B2), etc. That 

is, the outputs of each iteration are fed back and used as the keys at the next iteration. The 32-bit swapping 
function merely replaces 32-bit value B with 32-bit value D and 32-bit value D with 32-bit value B. 

In summary, the prior art describes a method for controlling key usage in cryptographic systems based 
on a symmetric key cryptographic algorithm such as the DEA. Key usage information is stored in a control 
so vector C which is cryptographically coupled with the key K using control vector encryption and control 
vector decryption algorithms, CVE and CVD, respectively. The CVE and CVD algorithms can handle both 
short and long control vectors. The only restriction on length is that the control vector must be a multiple of 
64 bits. The control vector itself consists of a group of subfields, where each subfield has it own definition 
and use within the key management to control the processing of the key. Encoding the control vector as a 
35 group of independent subfields has many advantages. The processing control vector checking need only 
concern itself with those subfields that pertain to the requested key usage. Thus, while the control vector 
may have many subfields, a particular cryptographic instruction may only need to check the encoded 
information in a few subfields. This speeds up the control vector checking process. Another important 
characteristic of the control vector is that the control vector accompanies (either explicitly or implicitly) the 
40 key wherever it goes. This is because the correct non-secret control vector must be specified to recover the 
correct secret key value. Thus, the control vector is available and can be checked at many different places 
within the cryptographic system: application program, cryptographic software, and cryptographic hardware. 

Within a cryptographic system, the CVE and CVD algorithms are implemented so that their operation is 
transparent to the system. All clear keys are encrypted with the CVE algorithm before the keys are output 
45 from the cryptographic hardware. All encrypted keys are decrypted with the CVD algorithm before they are 
processed within the cryptographic hardware. Even within the cryptographic hardware, these services can 
be provided transparently from the cryptographic instructions that process keys. By employing a single pair 
of control vector encryption and decryption functions, most of the complexity associated with key handling 
can be encoded as information fields within the control vector and within the checking processes 
so themselves, whereas the process of encrypting and decrypting keys and linking control vector information 
to the key can be handled with one common method. 

The present invention provides a method for incorporating control vectors into a key management 
scheme that uses a public key algorithm. The reader will appreciate that while the advantages of controlling 
key usage with the control vector are universal in nature, the methods for accomplishing this can vary 
55 depending on the attributes of the cryptographic algorithm employed. For example, consider the method of 
encrypting K with a variant key KK + C to produce eKK + C(K). In this case, K is encrypted using the Data 
Encryption Algorithm, in which case the Exclusive-OR product of KK and C is always guaranteed to 
produce a valid DEA key, as DEA keys, ignoring parity bits, are maximally dense in the set of ail binary 
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numbers of their magnitude. When the cryptographic algorithm is an asymmetric algorithm such as the RSA 
algorithm, there are two keys PU and PR. In general, if (PU.PR) is a valid key pair, then (PU + C.PR + C) is 
not a valid key pair for an arbitrary value C. This is because the PU and PR key values meet certain 
mathematical constraints and are sparse in the set of all binary numbers of their magnitude. Thus, an 

5 alternate method for coupling C to PU and PR is needed. Moreover, encrypting one key with another can 
sometimes be cumbersome, e.g., when an the RSA algorithm is employed it is cumbersome to encrypt a 
key of one modulus value with a key of another modulus value if the value of the first modulus is greater 
than the value of the second modulus. This cumbersome situation must be dealt with in the underlying 
design so that a general methodology is achieved. The present invention will show how this is accom- 

w plished. In hybrid cryptographic systems where both a symmetric and asymmetric algorithm are imple- 
mented, the public and private keys belonging to the asymmetric algorithm can be encrypted with keys 
belonging to the symmetric key algorithm. In that case, the method for coupling a key and control vector 
can be similar to that described in the prior art. However, even here there are subtle differences that affect 
the design choice. For example, the public and private keys belonging to the asymmetric key algorithm are 

75 typically longer than the keys belonging to the symmetric key algorithm. Also, the possibility that the public 
and private keys will be of different and varying lengths must be addressed. 512-bit RSA keys are not 
uncommon, where a DEA master key is generally 128 bits. Thus, the CVE and CVD algorithms must be 
adjusted to permit long asymmetric keys to be encrypted with shorter (e.g., 128-bit) symmetric keys. 
Another difference is that, in theory, the public keys need not be encrypted when stored in a cryptographic 

20 key data set. However, there are advantages to handling both the public and private keys similarly. As 
examples, the same method for coupling the control vector and the private key can be used to couple the 
control vector and the public key, and the same method of authenticating the key value can be used. Also, 
handling the public and private keys in the same way means that all keys are handled and processed just 
one way, which reduces the complexity of the key management design. That is, as the private key must be 

25 encrypted to ensure that its value does not become known, the public key may also be encrypted to 
simplify the internal key management design, as then the key (whether public or private) will always be 
decrypted before being processed further. 

When a public key algorithm is employed, the key lengths or key sizes are not fixed by the algorithm 
as with the DEA. In this case, the cryptographic system will most likely have to operate with public and 

30 private keys of different lengths, varying as much as several hundred bits. Therefore, the CVE and CVD 
algorithms must be designed to handle public and private keys with varying lengths. It is also important that 
the length of the key be made transparent from the application and the cryptographic system using the key. 

In cryptographic systems based on the DEA, many cryptographic instructions that handle bulk data 
must be streamlined so that performance is not degraded by the introduction of the control vector and the 

35 encryption and decryption algorithms (CVE and CVD). However, when a public key (PK) algorithm is 
employed, the individual steps of encryption and decryption are orders of magnitude slower than encryption 
and decryption with the DEA. Thus, the design of a key management scheme based on a PK algorithm can 
have different underlying objectives. For example, key processing and key handling operations that 
introduce unwarranted processing overhead in a DEA-based key management, may indeed be appropriate 

40 for a PK-based key management. This is because the processing overhead while large compared to one 
DEA encryption may be insignificant compared to one PK encryption. In the present invention, a strategy is 
pursued of authenticating a key dynamically within the cryptographic hardware as part of the CVD 
algorithm. Relatively speaking, while this introduces significant processing overhead in a DEA-based key 
management scheme, it adds very little processing overhead in a PK-based key management scheme. 

45 However, this ensures that valid and strong PR and PU keys are used, and that an invalid (i.e., insecure) 
key value is not inadvertently used. 

OBJECTS OF THE INVENTION 

so It is therefore an object of the invention to provide an improved method for controlling the usage of 
public and private keys. 

It is another object of the invention to permit large amounts of control information for the public and 
private keys. 

It is another object of the invention to permit the application, the system software, and the system 
55 hardware to check and set portions of the control information. 

It is another object of the invention to permit keys to be authenticated within the crypto hardware as 
part of the key recovery process, so that all keys are authenticated before they are used by the crypto 
hardware. 
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It is another object of the invention to permit an open-ended design allowing new and expanded key 
usage to be added to the architecture. 

It is another object of the invention to provide a single consistent method for handling both public and 
private keys. 

It is another object of the invention to allow the physical makeup of the keys to appear transparent. 

It is another object of the invention to allow users to port their public and private keys from one 
cryptographic system to another. 

It is another object of the invention to base control vector encrypt and decrypt on a DEA master key of 
128 bits. 

It is another object of the invention to provide a general method for control vector encrypt and decrypt 
where the system master key is a private and public key pair of a commutative asymmetric cryptographic 
algorithm (i.e., no DEA or other symmetric algorithm master key is used). 

It is another object of the invention to provide a general method for control vector encrypt and decrypt 
where the system master key is a quadruple of two key pairs of private and public keys of a non- 
commutative asymmetric cryptographic algorithm. Specifically the system master key quadruple consists of 
(1) a PU1 master key used to encrypt the public and private keys kept outside the cryptographic facility, (2) 
a PR1 master key used to decrypt the public and private keys kept outside the cryptographic facility, (3) a 
PR2 master key used to generate an authentication signature for the public and private keys kept outside 
the cryptographic facility, and (4) a PU2 master key used to verify the authentication signature of the public 
and private keys kept outside the cryptographic facility. 

It is another object of the invention to provide a general method for control vector encrypt and decrypt 
where the system master key is a quadruple of one key pair of private and public keys using public key 
algorithm 1 and another key pair of private and public keys using public key algorithm 2. Specifically the 
system master key quadruple consists of (1) a PU1 master key (based on public key algorithm 1) used to 
encrypt the public and private keys kept outside the cryptographic facility, (2) a PR1 master key (using 
public key algorithm 1) used to decrypt the public and private keys kept outside the cryptographic facility, 
(3) a PR2 master key (using public key algorithm 2) used to generate an authentication signature for the 
public and private keys kept outside the cryptographic facility, and (4) a PU2 master key (using public key 
algorithm 2) used to verify the authentication signature of the public and private keys kept outside the 
cryptographic facility. 

SUMMARY OF THE INVENTION 

These and other objects, features, and advantages are accomplished by the invention as claimed and 
disclosed herein. 

The invention describes a method for encrypting the public and private keys of a cryptographic 
asymmetric key (public key) algorithm, when these keys are stored outside the secure boundary of the 
cryptographic facility (i.e., cryptographic hardware) and for decrypting these keys when they are processed 
or used within the secure boundary of the cryptographic facility. The so-produced encrypted keys may be 
kept in a cryptographic key data set belonging to the cryptographic system software or they may be 
managed by the cryptographic application programs that use the keys. The public and private keys are 
encrypted by a system master key stored in clear form within the secure boundary of the cryptographic 
facility. In situations where the cryptographic system implements a symmetric key algorithm in addition to 
the asymmetric key algorithm the system master key can be a symmetric key. For example, if the 
cryptographic system implements both DEA and RSA algorithms, then the RSA public and private keys are 
protected with a 128-bit DEA master key. 

In situations where the cryptographic system implements a commutative asymmetric key algorithm 
(such as the RSA algorithm), the system master key consists of a special public and private key pair 
(PU0.PR0) stored in clear form within the cryptographic facility. A commutative asymmetric key algorithm is 
one where the operation of encryption followed by decryption is equal to the operation of decryption 
followed by encryption in that both result in the original plaintext. The master public key PUO is used to 
encrypt and verify authenticity for public and private keys stored outside the cryptographic facility and the 
master private key PRO is used to decrypt and generate authentication signatures on the public and private 
keys stored outside the cryptographic facility. In addition to providing a means to encrypt and decrypt the 
public and private keys stored outside the cryptographic facility, the invention also provides a means to 
cryptographically couple the control vector with the public and private keys and to authenticate the public 
and private keys using a special authenticator produced within the cryptographic facility. 
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In situations where the cryptographic system implements only a non-commutative asymmetric key 
algorithm, the system master key may consist of a special quadruple composed of a two public and private 
key pairs ((PU1,PR1),(PU2,PR2)) stored in clear form within the cryptographic facility. A non-commutative 
asymmetric key algorithm is one where encryption must always be done before decryption. Master public 
key PU1 is used to encrypt public and private keys stored outside the cryptographic facility and master 
private key PR1 is used to decrypt public and private keys stored outside the cryptographic facility. Master 
public key PU2 is used to verify the authenticity of and private keys stored outside the cryptographic facility 
and master private key PR2 is used to generate authentication signatures for the public and private keys 
stored outside the cryptographic facility. 

In situations where the cryptographic system implements two different asymmetric algorithms, where 
one algorithm is used for key encryption/decryption and another (different) algorithm is used for authentica- 
tion, the system master key consists of a special quadruple composed of a two public and private key pairs 
((PU1,PR1),(PU2,PR2)) stored in clear form within the cryptographic facility. (PU1.PR1) comprise an 
asymmetric key pair from a first public key algorithm and (PU2.PR2) comprise an asymmetric key pair from 
a second public key algorithm, which is different from the first algorithm. Master public key PU1 is used to 
encrypt public and private keys stored outside the cryptographic facility and master private key PR1 is used 
to decrypt public and private keys stored outside the cryptographic facility. Master public key PU2 is used 
to verify the authenticity of public and private keys stored outside the cryptographic facility and master 
private key PR2 is used to generate authentication signatures for the public and private keys stored outside 
the cryptographic facility. 

Note also, as an alternate embodiment, if the public key algorithm is not commutative, if both the public 
key and the private keys that are used as the master key pair are kept secret, then only one master key 
pair is needed. In this case, the (secret) public key is used to encrypt the authentication record and the 
private key is used to decrypt it. Normally this would represent a security exposure, but as the public key is 
secret and known only inside the cryptographic facility, there is no exposure. Care must be taken to ensure 
that the (secret) public key is never inadvertently exposed. 

Fig. 6 illustrates a cryptographic facility 30 containing a commutative asymmetric algorithm master key. 
In this case, the public and private keys stored outside the cryptographic facility 30 are protected (i.e., 
encrypted for privacy and authenticated) with an asymmetric master key pair, designated (PUO.PRO). 
Outside the cryptographic facility 30, all public and private keys are stored in key tokens. Public keys are 
stored in public key tokens (PU key tokens) and private keys are stored in private key tokens (PR key 
tokens). The PU key tokens and PR key tokens are stored in a cryptographic key data set 32 managed by 
the cryptographic system software, or they may be managed by the cryptographic application programs 
themselves (not shown in Fig. 6). 

Fig. 7 illustrates a cryptographic facility 30 containing an asymmetric key algorithm and a symmetric 
key algorithm. In this case, the public and private keys stored outside the cryptographic facility 30 are 
protected with a symmetric system master key, designated KM. If the symmetric key algorithm is the DEA, 
then KM is a 128-bit key, as described in the prior art. As in Fig. 6, the public and private keys are stored in 
PU key tokens and PR key tokens. The PU key tokens and PR key tokens are stored in a cryptographic 
key data set 32 managed by the cryptographic system software, or they may be managed by the 
cryptographic application programs themselves (not shown in Fig. 7). 

The reader will appreciate from the full description of the invention, provided below that, except for the 
special functions that encrypt and decrypt the keys in the key tokens, the means for protecting keys based 
on any of the following methods: 

(1) a symmetric system master key (KM), 

(2) a commutative asymmetric system master key pair (PUO.PRO), 

(3) a non-commutative asymmetric master key pair (PUO.PRO) where both the public and private key are 
kept secret, 

(4) a non-commutative asymmetric master key quadruple ((PU1,PR1),(PU2,PR2)), or 

(5) a master key quadruple ((PU1,PR1),(PU2,PR2)) when the first key pair uses one public key algorithm 
for key encryption/decryption and the second key pair uses another public key algorithm different from 
the first for authentication can be made transparent to the user of a cryptographic system. Thus, the 
cryptographic instructions that process and use the public and private keys and the cryptographic 
software and cryptographic application programs that handle the public and private key tokens are 
unaffected by the particular encryption and decryption means for storage and recovery of the public and 
private keys. This is so because the keys are treated as logical entities. Their physical characteristics 
such as length, format, component make up, etc., are kept transparent to the cryptographic system. This 
is partially accomplished through the use of special records called the public key record (PU key record) 
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and private key record (PR key record) which may have varying length, as the keys they contain may 
have varying length. All public and private keys generated within the cryptographic system are stored in 
these varying-length key records. As an alternate embodiment, the key records may be set to a fixed 
size that will contain the largest size public and private keys that will be generated and/or used on the 
5 system. 

Fig. 8 illustrates the production of public and private keys using a public key key generation algorithm 
(KGA) 152. In response to a request to generate a (PU.PR) key pair, public key generation algorithm 152 
causes a (PU.PR) key pair to be generated. The generated public key PU is stored in a PU key record and 
the generated private key PR is stored in a PR key record. The PU key record and PR key record are 

70 returned as outputs. In addition to returning the PU key record and PR key record, the public key 
generation algorithm 152 may also optionally return a PU_length parameter indicating the length of PU key 
record and a PR_length parameter indicating the length of PR key record. The optional length parameters 
may be useful in implementations where the lengths of PU key record and PR key record may vary. 

Fig. 9 illustrates the formats of the PU key record and PR key record. The PU key record contains 

75 parse data that permits the public key to be recovered from the record. The parse data may be length and 
displacement data of fields in the record. The PU key record also contains control information that may be 
useful in describing the record type and type of key or keys stored within the record. The PU key record 
also permits one or more public keys to be stored as a single logical public key. This may be particularly 
useful in situations where a first public key algorithm is used for DEA key encryption/decryption purposes, 

20 e.g., to distribute DEA keys from one device to another, and a second public key algorithm is used for 
generating and verifying digital signatures. Thus, a first public key PU1 is used to encrypt DEA keys and a 
second public key PU2 is used verify digital signatures. In such situations, the cryptographic system is 
designed in such a way that the key processing operations will know from the context of the operations 
being perform whether the public key to be used is PU1 or PU2. The PR key record also contains parse 

25 data that permits the private key to be recovered from the record. The PR key record also contains control 
information that may be useful in describing the record type and type of key or keys stored within the 
record. The PR key record also permits one or more private keys to be stored as a single logical private 
key. Thus, a first private key PR1 is used to decrypt a DEA key encrypted by the first public key PU1, and 
a second private key PR2 is used to generate digital signatures for later verification by the second public 

30 key PU2. In such situations, the cryptographic system is designed in such a way that the key processing 
operations will know from the context of the operations being performed whether the private key to be used 
is PR1 or PR2. The PU and PR key records keep algorithm specific and key specific information 
transparent to the cryptographic system. Only the public key algorithm itself that processes the key records 
need be aware of the internal structure and makeup of these key records. 

35 As an alternate embodiment, in certain situations, there may be advantages to maintaining the logical 
key records in two forms: the first containing both the private keys and public keys for the owner or creator 
of the keys and the second containing just the public keys for distribution to others. As before, if using the 
owner's logical key record containing both private and public keys, the correct key to use can be 
determined from context. 

40 Fig. 10 illustrates the production of public and private key pairs using a Generate Public and Private 
Key Pair (GPUPR) instruction. The GPUPR instruction is described in detail in co-pending patent application 
by S. M. Matyas, et al. entitled "Generating Public and Private Key Pairs Using a Passphrase", as cited in 
the background art. Referring now to Fig. 10, the GPUPR instruction 52 is contained in an instruction 
processor 142 within the cryptographic facility (CF) 30. In practice, the CF 30 is implemented within secure 

45 hardware, so that keys and cryptographic variables stored within the CF 30 are protected, i.e., both the 
secrecy and integrity of these keys and cryptographic variables are protected. The CF 30 also contains a 
CF environment memory 146 for the storage of keys and cryptographic variables such as a master key 15. 
Fig. 10 does not specify whether the master key is (1) a symmetric master key KM, (2) an asymmetric 
commutative master key pair (PUO.PRO), (3) a non-commutative asymmetric master key pair (PUO.PRO) 

so where both the public and private key are kept secret, (4) an asymmetric non- commutative master key 
quadruple ((PU1 ,PR1 ),(PU2,PR2)), or (5) an asymmetric two-PK-algorithm master key quadruple {- 
(PU1,PR1),(PU2,PR2)) where the first pair uses one public key algorithm and the second pair uses a 
different public key algorithm from the first. The CF 30 also contains cryptographic algorithms 144, which 
includes an asymmetric key algorithm 10, an optional symmetric key algorithm 11, and an asymmetric key 

55 key generation algorithm (KGA) 152. The inputs to the GPUPR instruction at 50 consist of a mode, an 
optional code word, PU control vector, and PR control vector. In response to a request to execute the 
GPUPR instruction at 50, the GPUPR instruction invokes the KGA 152, at 53, passing the mode and 
optional code word. The mode indicates to KGA 152 whether the to-be-generated public and private key 
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pair (PU,PR) are generated from a code word (mode = 'PP') or not (mode = 'no__PP'). In response the KGA 
152 produces a public and private key pair (PU.PR) which are formatted in a PU key record and PR key 
record. The PU key record and PR key record are returned to the GPUPR instruction at 54. In response, the 
GPUPR instruction builds a PU key token and a PR key token containing the encrypted PU key record and 

5 encrypted PR key record, respectively. Each key token contains a control vector and an authenticator, as 
further described below. The GPUPR instruction 52 also performs consistency checking on the mode and 
control vector supplied as inputs at 50, see also co-pending patent application by S. M. Matyas, et al. 
entitled "Generating Public and Private Key Pairs Using a Passphrase", cited in the background art, for a 
further discussion of this consistency checking. The so-produced PU key token and PR key token are 

w returned as outputs at 51 . 

Fig. 1 1 illustrates the formats of the PU key token and PR key token. The PU key token consists of a 
header, a PU control vector, an encrypted PU key record, and a PU authenticator. As an- alternate 
embodiment, the PU key token may consist of a header, a PU control vector, a plaintext PU key record, and 
a PU authenticator. The preferred embodiment has an encrypted PU key record in the PU key token as the 

75 PR key token must contain an encrypted PR key record (to maintain its secrecy) and doing both PU and 
PR key tokens in the same manner simplifies the processing. The PR key token consists of a header, a PR 
control vector, an encrypted PR key record, and a PR authenticator. The header in the PU key token 
consists of information (e.g., offsets or displacements to start of fields, offsets or displacements to end of 
fields, and/or lengths of fields) that enable the system to determine the start and end of each other field in 

20 the PU key token. The PU control vector consists of a PU key type, PU key usage data, PR key usage data 
(for history purposes), algorithm identifier, algorithm-specific data, key start date/time, key expiration 
data/time, device identifier, user identifier, key identifier, logical device identifier, and user-defined data. The 
fields of PU control vectors are presented in more detail under "Description of the Best Mode for Carrying 
Out the Invention." If the system master key is a symmetric key KM, then PU key record is encrypted with 

25 a variant key derived from KM, as explained below. If the system master key is an asymmetric key pair 
(PUO.PRO), then PU key record is encrypted with PUO, as explained below. The PU authenticator is a 
special authentication code produced at the time the PU key token is constructed. Later, when the PU key 
token is specified as a parameter input to a cryptographic instruction, the PU authenticator is used to 
validate the public key as part of key recovery, before the recovered PU is processed within the 

30 cryptographic instruction. 

The header in the PR key token consists of information (e.g., offsets or displacements to start of fields, 
offsets or displacements to end of fields, and/or lengths of fields) that enable the system to determine the 
start and end of each other field in the PR key token. The PR control vector consists of a PR key type, PR 
key usage data, PU key usage data (for history purposes), algorithm identifier, algorithm-specific data, key 

35 start date/time, key expiration data/time, device identifier, user identifier, key identifier, logical device 
identifier, and user-defined data. The fields of PR control vectors are presented in more detail under 
"Description of the Best Mode for Carrying Out the Invention." If the system master key is a symmetric key 
KM, then PR key record is encrypted with a variant key derived from KM, as explained below. If the system 
master key is an asymmetric key pair (PUO.PRO), then the PR key record is encrypted with PUO, as 

40 explained below. The PR authenticator is a special authentication code produced at the time the PR key 
token is constructed. Later, when the PR key token is specified as a parameter input to a cryptographic 
instruction, the PR authenticator is used to validate the public key as part of key recovery, before the 
recovered PR is processed within the cryptographic instruction. 

In co-pending patent application by S. M. Matyas, et al. entitled "Generating Public and Private Key 

45 Pairs Using a Passphrase", cited in the background art, the outputs of key generator algorithm 152 are the 
generated public and private keys, PU and PR. Actually, the outputs are a PU key record and a PR key 
record, containing the generated PU and PR, respectively, as defined here. Those skilled in the art will 
appreciate that the description of the GPUPR instruction and the key generation algorithm in copending 
patent application by S. M. Matyas, et al. entitled "Generating Public and Private Key Pairs Using a 

50 Passphrase", is for all intents and purposes the same as the description provided here, and that returning 
PU and PR as outputs from the key generation algorithm 152, instead of return PU and PR key records 
does not depart from the underlying invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 

These and other objects, features, and advantages of the invention will be more fully appreciated with 
reference to the accompanying figures. 
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Fig. 1 is a block diagram illustration of the process to encrypting keys and decrypting keys in a DEA- 
based cryptographic system using the control vector encrypt (CVE) and control vector decrypt (CVD) 
algorithms. 

Fig. 2 is a block diagram illustration of the CVE algorithm implemented in a DEA-based cryptographic 
system. 

Fig. 3 is a block diagram illustration of the CVD algorithm implemented in a DEA-based cryptographic 
system. 

Fig. 4 is a block diagram illustration of the hashing algorithm ha implemented in the CVE and CVD 
algorithms of Figs. 1, 2, and 3. 

Fig. 5 is a block diagram illustration of the MDC-2 algorithm. 

Fig. 6 is a block diagram illustration of a first embodiment of the invention wherein the generated public 
and private keys stored outside the cryptographic facility are protected with a commutative asymmetric 
system master key pair (PU0.PR0). 

Fig. 7 is a block diagram illustration of a second embodiment of the invention wherein the generated 
public and private keys stored outside the cryptographic facility are protected with a symmetric system 
master key KM. 

Fig. 8 is a block diagram illustration of a public key key generation algorithm (KGA). 

Fig. 9 illustrates the formats of the PU key record and PR key record. 

Fig. 10 is a block diagram illustration of the GPUPR instruction. 

Fig. 11 illustrates the formats of the PU key token and the PR key token. 

Fig. 12 illustrates a communications network 10 including a plurality of data processors, each of which 
includes a cryptographic system. 

Fig. 13 is a block diagram of a cryptographic system 22. 
Fig. 14 is a block diagram of a cryptographic facility 30. 

Fig. 15 is a block diagram illustration of the cryptographic algorithms 144 component of the cryp- 
tographic facility 30 containing the key record encrypt and key record decrypt algorithms. 

Fig. 16 is a flow diagram of a first embodiment of key record encrypt algorithm 12. 

Fig. 17 is a flow diagram of a first embodiment of key record decrypt algorithm 13. 

Fig. 18 is a flow diagram of a second embodiment of key record encrypt algorithm 12. 

Fig. 19 is a flow diagram of a second embodiment of key record decrypt algorithm 13, 

Fig. 20 is a functional block diagram illustrating the recovery of two private keys and their use in two 
public key algorithms to fulfill two different cryptographic service requests. 

Fig. 21 is a block diagram showing the production of an internal key token from a key record and the 
production of an external key token from a key record. 

Fig. 22 is a block diagram showing the production of an internal key token from an internal key unit 
produced from a key record and the production of an external key token from an external key unit produced 
from a key record. 

Fig. 23 lists the components of the Instruction Processor 142. 

Fig. 24 shows the elements of the Configuration Table in the CF Environment Memory 146. 
Fig. 25 shows the main elements of the Cryptographic Algorithms 144. 
Fig. 26 is a block diagram illustration of the components of the CF Environment. 
Fig. 27 shows the instructions controlled by the DEFINE, AUTH CONTROL, AUTH, and ENABLE fields 
in the Configuration Vector. 

Fig. 28 is a block diagram illustration of the MDC Table. 
Fig. 29 is a block diagram illustration of the Counter Table. 
Fig. 30 illustrates the control vector hierarchy of PKCD keys. 

Fig. 31 is a block diagram illustration of the fields in a control vector associated with a private 
authentication key. 

Fig. 32 is a block diagram illustration of the fields in a control vector associated with a private 
certification key. 

Fig. 33 is a block diagram illustration of the fields in a control vector associated with a private key 
management key. 

Fig. 34 is a block diagram illustration of the fields in a control vector associated with a private user key. 
Fig. 35 is a block diagram illustration of the fields in a control vector associated with a public 
authentication key. 

Fig. 36 is a block diagram illustration of the fields in a control vector associated with a public 
certification key. 
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Fig. 37 is a block diagram illustration of the fields in a control vector associated with a public key 
management key. 

Fig. 38 is a block diagram illustration of the fields in a control vector associated with a public user key. 
Fig. 39 is a block diagram illustration of the fields in a hash vector. 

5 

DESCRIPTION OF MODES FOR CARRYING OUT THE INVENTION 

Environment Description: Fig. 12 illustrates a network block diagram showing a communications network 10 
to which is connected a plurality of data processors including data processor 20, data processor 20\ and 

w data processor 20". Also included in each data processor is a cryptographic system, as shown in Fig. 12. 
Data processor 20 includes cryptographic system 22, data processor 20* includes cryptographic system 22' 
and data processor 20" includes cryptographic system 22". Each data processor supports the processing 
of one or more applications which require access to cryptographic services such as for the encryption, 
decryption and authenticating of application data and the generation and installation of cryptographic keys. 

75 The cryptographic services are provided by a secure cryptographic facility in each cryptographic system. 
The network provides the means for the data processors to send and receive encrypted data and keys. 
Various protocols, that is, formats and procedural rules, govern the exchange of cryptographic quantities 
between communicating data processors in order to ensure the interoperability between them. 

Fig. 13 illustrates the cryptographic system 22. In the cryptographic system 22, the cryptographic 

20 facility (CF) 30 has an input 37 from a physical interface. The cryptographic facility access program (CFAP) 
34 is coupled to the cryptographic facility 30 by means of the interface 31. The cryptographic key data set 
(CKDS) 32 is connected to the cryptographic facility access program 34 by means of the interface 33. The 
application programs (APPL) 36 are connected to the cryptographic facility access program 34 by means of 
the interface 35. 

25 A typical request for cryptographic service is initiated by APPL 36 via a function call to the CFAP 34 at 
the interface 35. The service request includes key and data parameters, as well as key identifiers which the 
CFAP 34 uses to access encrypted keys from the CKDS 32 at the interface 33. The CFAP 34 processes the 
service request by issuing one or more cryptographic access instructions to the CF 30 at the interface 31. 
The CF 30 may also have an optional physical interface 37 for direct entry of cryptographic variables into 

30 the CF 30. Each cryptographic access instruction invoked at the interface 31 has a set of input parameters 
processed by the CF 30 to produce a set of output parameters returned by the CF 30 to the CFAP 34. In 
turn, the CFAP 34 may return output parameters to the APPL 36. The CFAP 34 may also use the output 
parameters and input parameters to subsequently invoke instructions. If the output parameters contain 
encrypted keys, then the CFAP 34, in many cases, may store these encrypted keys in the CKDS 32. 

35 Fig. 14 illustrates the cryptographic facility 30. The cryptographic facility 30 is maintained within a 
secure boundary 140. The cryptographic facility 30 includes the instruction processor 142 which is coupled 
to the cryptographic algorithms 144 which are embodied as executable code. The cryptographic facility 
environment memory 146 is coupled to the instruction processor 142. The physical interface can be 
coupled over line 37 to the CF environment memory 146, as shown in the figure. The instruction processor 

40 142 is coupled to the cryptographic facility access program (CFAP) 34 by means of the interface at 31. 

The instruction processor 142 is a functional element which executes cryptographic microinstructions 
invoked by the CFAP access instruction at the interface 31. For each access instruction, the interface 31 
first defines an instruction mnemonic or operation code used to select particular microinstructions for 
execution. Secondly a set of input parameters is passed from the CFAP 34 to the CF 30. Thirdly, a set of 

45 output parameters is returned by the CF 30 to the CFAP 34. The instruction processor 142 executes the 
selected instruction by performing an instruction specific sequence of cryptographic processing steps 
embodied as microinstructions stored in cryptographic microinstruction memory 144. The control flow and 
subsequent output of the cryptographic processing steps depend on the values of the input parameters and 
the contents of the CF environment memory 146. The CF environment memory 146 consists of a set of 

so cryptographic variables, for example keys, flags, counters, CF configuration information, etc., which are 
collectively stored within the CF 30. The CF environment variables in memory 146 are initialized via the 
interface 31 , that is by execution of certain CF microinstructions which read input parameters and load them 
into the CF environment memory 146. Alternately, initialization can be done via an optional physical 
interface which permits cryptographic variables to be loaded directly into the CF environment memory 146, 

55 for example via an attached key entry device. 

The physical embodiment of the cryptographic facility secure boundary 140, incorporates the following 
physical security features. The physical embodiment resists probing by an insider adversary who has 
limited access to the cryptographic facility 30. The term "limited" is measured in minutes or hours as 
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opposed to days or weeks. The adversary is constrained to a probing attack at the customer's site using 
limited electronic devices as opposed to a laboratory attack launched at a site under the control of the 
adversary using sophisticated electronic and mechanical equipment. The physical embodiment also detects 
attempts at physical probing or intruding, through the use of a variety of electro-mechanical sensing 

5 devices. Also, the physical embodiment of the cryptographic facility 30 provides for the zeroization of all 
internally stored secret cryptographic variables. Such zeroization is done automatically whenever an 
attempted probing or intrusion has been detected. The physical embodiment also provides a manual facility 
for a zeroization of internally stored secret cryptographic variables. Reference to the Abraham, et al. patent 
application cited above, will give an example of how such physical security features can be implemented. 

w Key Record Encryption/Decryption: Fig 15 is a block diagram illustration of cryptographic facility 30 
incorporating the key record encrypt and key record decrypt algorithms. Cryptographic facility 30 contains 
an instruction processor 142 consisting of a plurality of cryptographic instructions (not shown in Fig. 15), a 
CF environment memory 146 containing a master key 15, and cryptographic algorithms 144. Cryptographic 
algorithms 144 contains an asymmetric key cryptographic algorithm 10, an optional symmetric-key cryp- 

75 tographic algorithm 11, an asymmetric-key key generation algorithm 152, a key record encrypt algorithm 
12, and a key record decrypt algorithm 13. Key record encrypt algorithm 12 is a low-level function used by 
instruction processor 142 to encrypt a key record (PU key record or PR key record) and produce an 
encrypted key authenticator record (KAR), which serves to authenticate the key record and associated 
control vector to the cryptographic facility 30. During key generation (via the GPUPR instruction), the PU 

20 and PR key records produced by the asymmetric key key generation algorithm 152 are encrypted and then 
stored in key tokens constructed by the instruction processor. These key tokens are returned as outputs at 
51. The key record encrypt algorithm 12 is invoked by the instruction processor 142 at 14, passing a key 
record and control vector. In response, key record encrypt algorithm 12 encrypts the key record with master 
key 15, or a variant key derived from master key 15, as explained below. Key record encrypt algorithm 12 

25 also produces a key authenticator record (KAR) from the key record or from the control vector and key 
record, again as explained below. The so-produced KAR is then encrypted with master key 15, or a variant 
key derived from master key 15 (different from the variant key used to encrypt the key record), as 
explained below. Note that if the KAR was not encrypted, this might represent a security exposure, as the 
control vector and key record for a public key and the KAR generation algorithm are all assumed to be 

30 public knowledge. This would possibly allow substitution of a incorrect public key or incorrect control vector 
for the correct values, for example, in the cryptographic key data set. While the KAR for a private key may 
not need to be encrypted for security, in the preferred embodiment, it is encrypted to allow consistent 
processing of the KAR for both public and private keys. As an alternate embodiment, the KAR for the 
private key could just be the output of a strong cryptographic one-way function, such as the MDC-2 function 

35 described elsewhere. The encrypted key record and encrypted KAR are returned at 16 to the instruction 
processor 142. Key record decrypt algorithm 13 is a low-level function used by instruction processor 142 to 
decrypt a key record (PU key record or PR key record) and authenticate the key record and associated 
control vector to the cryptographic facility 30 before permitting instruction processor 142 to process or use 
the key in the decrypted key record. Many of the cryptographic instructions executing in the instruction 

40 processor 142 make use of cryptographic keys stored in key tokens and supplied as inputs at 50 to the 
instruction processor 142. Before a key can be processed or used by the instruction processor 142, it must 
be recovered. During key recovery, the encrypted PU and PR key records contained in the input key tokens 
(at 50) are decrypted and authenticated. The key record decrypt algorithm 13 is invoked at 17 by the 
instruction processor 142, passing a key record and control vector as inputs. In response, key record 

45 decrypt algorithm 13 decrypts the encrypt key record with master key 15, or a variant key derived from 
master key 15, as explained below. Key record decrypt algorithm 13 also produces a key authenticator 
record (KAR) from the recovered key record, or from the control vector and recovered key record, again as 
explained below. The key record decrypt algorithm 13 then decrypts the encrypted KAR and compares the 
recovered value of KAR and the generated or produced KAR for equality. If the two values of KAR are 

so equal, the key record decrypt algorithm 13 returns the recovered key record and a return code (e.g., 
RC=0) indicating that the key record has been successfully authenticated via the KAR. Otherwise, if the two 
value of KAR are unequal, the key record decrypt algorithm 13 returns only a return code (e.g., RC = 1) 
indicating that the key record has failed to be authenticated via the KAR. 

Fig. 16 is block diagram illustration of a first embodiment of the key record encrypt algorithm 12. The 

55 first embodiment of the invention covers the case where the cryptographic system implements both a 
symmetric key algorithm and an asymmetric key algorithm, and where the master key used to encrypt the 
key records in the key tokens stored outside the cryptographic facility is a symmetric key KM. Referring 
now to Fig. 16, the inputs (a) key record and (b) control vector are read at step 500. Key record is the key 
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record to be encrypted and control vector is key-related data, or data related to the key stored in key 
record. Control vector is the same control vector stored in the key token, as described in Fig. 11. At step 
501 , a hash value HASH1 is calculated on the control vector using hash algorithm ha1 . For example, when 
the master key is a 128-bit DEA master key, HASH1 can be a 128-bit MDC calculated with the MDC-2 
5 algorithm of Fig. 5. At step 502, hash vectors H1 and H2 are calculated from HASH1. For example, when 
the master key is a 128-bit DEA master key and H1 and H2 are both 128-bit hash vectors, the procedure for 
calculating H1 and H2 is as follows. The 128-bit hash vector H1 is calculated from HASH1 as follows: 

1. Set bit 30 of HASH1 equal to B'0\ 

2. Set bit 38 of HASH1 equal to BT. 

10 3. Set bits 45.-46 of HASH1 equal to B'10\ 

4. Set bit 62 of HASH1 equal B'0\ 

5. For each byte in HASH1 (bits are numbered bO through b7) t set bit b7 so that bits bO through b7 have — ~ 
an even number of one bits (i.e., to have even parity). 

Bits 30 and 38 are anti-variant bits whose values are set so that the resulting hash vector H is guaranteed to 
75 be different from a variant value in which each byte of the variant has the same bit pattern. Bits 45 and 46 
are set to B'10' to distinguish H1 from a 64-bit control vector (bits 45..46 equal to BW) and a 128-bit 
control vector (bits 45..46 equal to B'01'). In this case, B'10' indicates that H1 has been derived from a 
"long" control vector whose length exceeds 128 bits. Bit 62 indicates whether the control vector is 
associated with a key record (B'0') or a key authenticator record (BT). The 128-bit hash vector H2 is 
20 calculated from H1 as follows: 
1.SetH2 equal to HI. 

2. Set bit 62 of H2 equal to BT. 

3. Invert bit 63 of H2 (i.e., the parity bit). 

Basically, H2 differs from H1 only in that H1 is associated with a key record (bit 62 equals B'0') and H2 is 

25 associated with a key authenticator record (bit 62 equals BT). The parity bit is adjusted to maintain even 
parity. Otherwise, H1 and H2 are equal. At step 503, variant key KM + H1 is formed as the Exclusive-OR 
product of master key KM and hash vector H1 and variant key KM + H2 is formed as the Exclusive-OR 
product of master key KM and control vector H2. In the event that the length of KM differs from the length 
of H1 and H2, H1 and H2 can be Exclusive-ORed with a portion of KM only. Those skilled in the art will 

30 recognize that a combining operation other than the Exclusive-OR operation can be performed instead of 
the Exclusive-OR operation, without departing from the spirit of the invention. When KM is a DEA master 
key of 128 bits, then the Exclusive-OR operation calculates the Exclusive-OR product of two 128-bit values, 
which is the straightforward way in which this operation works. At step 504, the key record supplied as input 
at 500 is encrypted with variant key KM + H1 to produce the encrypted key record value eKM + H1(key 

35 record). Again, those skilled in the art will recognize that many different modes of encryption can be used 
here, since the goal is to protect the secrecy of the key record but not necessarily to pursue one single 
strategy for providing an encryption capability. For example, if the variant key KM + H1 is a 64-bit DEA key, 
then the key record can be encrypted using the Cipher Block Chaining (CBC) mode of encryption. If the 
variant key KM + H1 is a 128-bit DEA key, then key record can be encrypted using a variation on the CBC 

40 mode of encryption. In that case, key record is first encrypted with CBC mode using the leftmost 64 bits of 
KM + H1, the result is next decrypted with CBC mode using the rightmost 64-bits of KM + H1, and finally 
that result is encrypted with CBC mode using the leftmost 64-bits of KM + H1. An initialization vector (IV) of 
zero is used throughout the encryption and decryption operations. In each case, inverse decryption 
operations are employed in the key record decrypt algorithm, discussed below. Those skilled in the art will 

45 recognize that encryption methods other than those illustrated here can be used without departing from the 
spirit of the invention. At step 505, a hash value HASH2 is calculated on key record using hash algorithm 
ha2. Hash algorithm ha2 may be different from hash algorithm hal or it may be the same. For example, 
hash algorithm ha2 may be the MDC-2 algorithm of Fig. 5 and HASH2 a 128-bit MDC value. The value 
HASH2 is for practical purposes defined to be the key authenticator record (KAR). However, the KAR may 

50 contain additional data besides HASH2. At step 506, KAR is encrypted with variant key KM + H2 to produce 
the encrypted KAR value eKM + H2(KAR). Again, those skilled in the art will recognize that many different 
modes of encryption can be used here, since the goal is to protect the integrity of the KAR by making it 
infeasible for an adversary to substitute an alternate value of KAR of his or her choosing. Since an 
adversary has no ability to exercise the encryption function using KM + H2, it is not possible to substitute an 

55 encrypted KAR value that will authenticate an encrypted key record, except by mere chance. For example, 
if the variant key KM + H2 is a 64-bit DEA key, then KAR can be encrypted using the Cipher Block Chaining 
(CBC) mode of encryption. If the variant key KM + H2 is a 128-bit DEA key, then KAR can be encrypted 
using a variation on the CBC mode of encryption as described above for the encryption of the key record. 
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In each case, inverse decryption operations are employed in the key record decrypt algorithm, discussed 
below Those skilled in the art will recognize that encryption methods other than those illustrated here can 
be used without departing from the spirit of the invention. At step 507, the calculated values (a) eKM + H1- 
(key record) and (b) eKM + H2(KAR) are returned as outputs. 

Fig. 17 is block diagram illustration of a first embodiment of the key record decrypt algorithm 13. The 
first embodiment of the invention covers the case where the cryptographic system implements both a 
symmetric key algorithm and an asymmetric key algorithm, and where the master key used to encrypt the 
key records in the key tokens stored outside the cryptographic facility is a symmetric key KM. The key 
record encrypt algorithm 12 of Fig. 16 and the key record decrypt algorithm 13 of Fig. 17 are inverse 
algorithms ie., key records encrypted with key record encrypt algorithm 12 of Fig. 16 are decrypted with 
key record decrypt algorithm 13 of Fig. 17. Referring now to Fig. 17, the inputs (a) control vector, (b) 
eKM + H1(key record), and (c) eKM + H2(KAR) are read at step 510. Control vector is key-related data, or 
data related to the key stored in key record. Control vector is the same control vector stored in the key 
token as described in Fig. 11. eKM + H1(key record) and eKM + H2(KAR) are values produced by the key 
record encrypt algorithm 12 of Fig. 16. At step 511, a hash value HASH1 is calculated on the control vector 
using hash algorithm hal using the same method as described in step 501 of Fig. 16. At step 512, hash 
vectors H1 and H2 are calculated from HASH1 using the same method as described in step 502 of Fig. 16. 
At step 513 variant keys KM + H1 and KM + H2 are calculated from master key KM and hash vectors H1 
and H2 using the same method as described in step 503 of Fig. 16. At step 514, the encrypted key record, 
eKM + HI (key record), supplied as input at 510 is decrypted with variant key KM + H1 to produce the clear 
value of key record. The method of decryption at step 514 of Fig. 17 is just the inverse operation of 
encryption at step 504 of Fig. 16. At step 515, a hash value HASH2 is calculated on key record using hash 
algorithm ha2. Step 515 of Fig. 17 is the same as step 505 of Fig. 16. At step 516, the encrypted KAR, 
eKM + H2(KAR), supplied as input at 510, is decrypted with variant key KM + H2 to produce the clear value 
of KAR. The method of decryption at step 516 of Fig. 17 is just the inverse operation of encryption at step 
506 of Fig. 16. At step 517, the generated KAR is compared for equality with the decrypted KAR. If equal, 
then a return code is set equal to "success". If unequal, then a return code is set equal to "failure" and key 
record is set equal to null (i.e., the recovered key record is erased). At step 518, the values of (a) return 
code and (b) key record are returned as outputs. If the key record authenticates properly, it is returned as 
an output at step 518. Otherwise a null value is returned. Those skilled in the art will recognize that there 
are other ways in which the output values can be returned or not returned. The intent here is for key record 
decrypt algorithm 13 to return the recovered key record when it authenticates properly and to not return it 
when it does not authenticate properly. The return code could be omitted from the design, if desired, 
provided that a protocol is adopted wherein the key record has a special reserved value, say zero, to 
indicate a failure condition (a nonzero value indicates success). 

Fig 18 is block diagram illustration of a second embodiment of the key record encrypt algorithm 12. 
The second embodiment of the invention covers the case where the cryptographic system implements an 
commutative asymmetric key algorithm, and where the master key is an asymmetric key pair (PU0.PR0). 
Master public key PU0 is used to encrypt key records and to verify digital signatures. Master private key 
PRO is used to decrypt key records and to generate digital signatures. Refening now to Fig. 18, the inputs 
(a) key record and (b) control vector are read at step 520. Key record is the key record to be encrypted and 
control vector is key-related data, or data related to the key stored in key record. Control vector is the same 
control vector stored in the key token, as described in Fig. 11. At step 521, the key record supplied as input 
at 520 is encrypted with public master key PU0 to produce the encrypted key record value ePU0(key 
record) Since the length of key record may be greater than the block size (or modulus size) of the 
asymmetric key algorithm, an encryption means must be employed to handle "long" key records. One 
approach is to use a means similar to Cipher Block Chaining (CBC) mode, as defined for the DEA. In this 
case key record is divided into blocks whose length is such that each block can be encrypted with the 
asymmetric key algorithm. After each step of encryption, the so-produced ciphertext block is Exclusive- 
ORed with the next block of input plaintext in key record. Those skilled in the art will appreciate that there 
are many ways in which the encryption with PU0 can be performed and that these various alternate means 
do not depart from the spirit of the invention. At step 522 control vector and key record are concatenated to 
form an intermediate value called HA-IN. At step 523, a hash value HASH2 is calculated on HA-IN using 
hash algorithm ha2. For example, hash algorithm ha2 may be the MDC-2 algorithm of Fig. 5 and HASH2 a 
128-bit MDC value. The value HASH2 is for practical purposes defined to be the key authenticator record 
(KAR) However, the KAR may contain additional data besides HASH2. At step 524, KAR is decrypted with 
private master key PRO to produce dPRO(KAR). In public key cryptography, the ciphertext dPRO(KAR) is 
called a digital signature. In this case, dPRO(KAR) is a digital signature on HA-IN (the concatenation of 
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control vector and key record). At step 525, the calculated values (a) ePU0(key record) and (b) dPRO(KAR) 
are returned as outputs. 

Fig. 19 is block diagram illustration of a second embodiment of the key record decrypt algorithm 13. 
The second embodiment of the invention covers the case where the cryptographic system implements a 

5 commutative asymmetric key algorithm, and where the master key is an asymmetric key pair (PUO.PRO). 
Master public key PUO is used to encrypt key records and to verify digital signatures. Master private key 
PRO is used to decrypt key records and to generate digital signatures. The key record encrypt algorithm 12 
of Fig. 18 and the key record decrypt algorithm 13 of Fig. 19 are inverse algorithms, i.e., key records 
encrypted with key record encrypt algorithm 12 of Fig. 18 are decrypted with key record decrypt algorithm 

w 13 of Fig. 19. Referring now to Fig. 19, the inputs (a) control vector, (b) ePU0(key record), and (c) dPRO- 
(KAR) are read at step 530. Control vector is key-related data, or data related to the key stored in key 
record. Control vector is the same control vector stored in the key token, as described in Fig. 11. ePU0(key 
record) and dPRO(KAR) are values produced by the key record encrypt algorithm 12 of Fig. 18. At step 531, 
the encrypted key record, ePU0(key record), supplied as input at 530 is decrypted with private master key 

75 PRO to produce a clear key record. The step of decryption is just the inverse operation of encryption 
performed at step 521 of Fig. 18. At step 532, control vector supplied as input at 530 and key record 
recovered at 531 are concatenated to form an intermediate value called HA-IN. Step 532 is just the same as 
step 522 in Fig. 18. At step 533, a hash value HASH2 is calculated on HA-IN using hash algorithm ha2. The 
value HASH2 is for practical purposes defined to be the key authenticator record (KAR). However, the KAR 

20 may contain additional data besides HASH2. Step 533 is just the same as step 523 in Fig. 18. At step 534, 
the decrypted KAR, dPRO(KAR), is encrypted with public master key PUO to produce a clear value of KAR 
(called the recovered KAR). Note that this is the step that requires the asymmetric key algorithm be 
commutative. At step 535, the generated KAR is compared for equality with the recovered KAR. If equal, 
then a return code is set equal to "success". If unequal, then a return code is set equal to "failure" and key 

25 record is set equal to null (i.e., the recovered key record is erased). At step 536, the values of (a) return 
code and (b) key record are returned as outputs. If the key record authenticates properly, it is returned as 
an output at step 536. Otherwise a null value is returned. Those skilled in the art will recognize that there 
are other ways in which the output values can be returned or not returned. The intent here is for key record 
decrypt algorithm 1 3 to return the recovered key record when it authenticates properly and to not return it 

30 when it does not authenticate properly. The return code could be omitted from the design, if desired, 
provided that a protocol is adopted wherein the key record has a special reserved value, say zero, to 
indicate a failure condition (a nonzero value indicating success). 

Those skilled in the art will recognize that step 521 in Fig. 18 could make use of a decryption operation 
using the public master key PUO and step 531 of Fig. 19 could likewise make use of an encryption 

35 operation using the private master key PRO. In like manner, step 524 in Fig. 18 could make use of an 
encrypt operation using private master key PRO and step 534 of Fig. 19 could make use of a decrypt 
operation using public master key PUO, as long as both the public key PUO and private key PRO remain 
secret. In fact, the choice of encrypt or decrypt at step 521 of Fig. 18 is independent of the choice of 
encrypt or decrypt at step 524 of Fig. 18, so that alternate embodiments of the invention can make use of 

40 these alternate schemes of encryption versus decryption or decryption versus encryption. And those skilled 
in the art will recognize that these alternate embodiments do not depart from the spirit of the invention. 

Those skilled in the art will also recognize that the key record encrypt algorithm 12 of Fig. 18 and the 
key record decrypt algorithm 13 of Fig. 19 could make use of a symmetric master key KM instead of a 
public and private master key (PU0.PR0). In that case, all operations performed with PUO and PRO are 

45 instead performed with KM. In an alternate approach, variant keys KM1 and KM2 (not equal to KM1) can be 
used as the master key. In this case, KM1 is used in place of PUO and KM2 is used in place of PRO. This 
provides a form of cryptographic separation between the encryption and authentication components of the 
design. Thus, encryption of the key record is performed with KM1 and encryption of the KAR is performed 
with KM2. Those skilled in the art will appreciate that these alternate embodiments do not depart from the 

50 spirit of the invention. 

Fig. 20 shows a functional block diagram of the cryptographic facility 30, for recovering a plurality of 
public and/or private keys from a key token for use in a plurality of public key algorithms, in response to a 
plurality of diverse cryptographic service requests. In particular, Fig. 20 depicts how two private keys, PR1 
and PR2 can be recovered from a key token accessed from the cryptographic key data set CKDS 32 for 
55 use in two different public key algorithms, to fulfill two different cryptographic service requests. The first 
request R1 is to import the encrypted DEA key ePU1(key1), which was encrypted under a first public key 
PU1, and decrypt the key under the corresponding private key PR1 to obtain keyl, using a first public key 
algorithm A1 . The second request R2 is to generate a digital signature from Data2 under a second private 
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key PR2, using a second public key algorithm A2. 

The key token is input from the CKDS on line 50 to the key token register 700, with the header portion 
in the component register 704 and the concatenated control vector CV, encrypted key record eKM + H1- 
(parse,Ctl,PR1,PR2) and encrypted key authentication record eKM + H2(KAR) in the component register 702. 

5 The header in register 704 defines the beginning and ending of the control vector, the encrypted key record 
and the encrypted key authentication record in register 702. The header register 704 output is connected to 
a control input of the multiplexor 706, which separates the control vector for output over line 17 to the 
control vector register 708, which separates the encrypted key record for output to the encrypted key 
record register 710 and which separates the encrypted key authentication record for output to the encrypted 

10 key authentication register 712. 

The control vector checker 714 receives the control vector CV from the register 708. If the import DEA 
Key request R1 is the cryptographic service request which has been made, then the control vector checker 
receives R1 and performs the checking operations on CV to ensure that the key record contains a key 
which is permitted to be applied to this use. If CV satisfies the control vector checker 714, then an enabling 

15 signal "ok" is sent to the gate 716, whose data input is connected to the output of the control vector register 
708, passing CV to the control vector input of the key record decrypt algorithm 718 and 720. If CV fails to 
pass the checks by the control vector checker 714, then the process is aborted. 

Alternately, if the Generate Digital Signature request R2 is the cryptographic service request which has 
been made, then the control vector checker receives R2 and performs the checking operations on CV to 

20 ensure that the key record contains a key which is permitted to be applied to this use. If CV satisfies the 
control vector checker 714, then an enabling signal "ok" is sent to the gate 716, whose data input is 
connected to the output of the control vector register 708, passing CV to the control vector input of the key 
record decrypt algorithm 718 and 720. If CV fails to pass these checks by the control vector checker 714, 
then the process is aborted. 

25 The key record decrypt algorithm 13 in the flow diagram of Fig. 17 is executed by the functional blocks 
718, 720, 722, 724, and 726 of Fig. 20. Two functional blocks, 718 and 720, are arranged in parallel and are 
labeled "Key Record Decrypt Algorithm", in Fig. 20, to provide a clear description of the decryption 
operations on the encrypted key record and on the encrypted key authentication record. However, in the 
preferred embodiment of the invention, the two functional blocks 718 and 720 would be combined into a 

30 single Key Record Decrypt Algorithm which would operate sequentially on the encrypted key record and on 
the encrypted key authentication record. Doing so enables second hash vector H2 to be produced from first 
hash vector H1 by changing only a single bit in H1. The key record decrypt algorithm 718 receives CV and 
performs the hashing operation described in steps 511 and 512 of Fig. 17, producing the hash vector H1. 
The master key KM is input from register 15 and the exclusive OR product with H1 is formed, yielding the 

35 variant key KM + H1, as described in step 513 of Fig. 17. The second key record decrypt algorithm 720 
receives CV and performs the hashing operation described in steps 511 and 512 of Fig. 17, producing the 
second hash vector H2. The master key KM is input from register 15 and the exclusive OR product with H2 
is formed, yielding the second variant key KM + H2, as described in step 513 of Fig. 17. The first key record 
decrypt algorithm 718 then uses the variant key KM + H1 to decrypt the encrypted key record, as described 

40 in step 514 of Fig. 17, yielding the key record (parse,Ctl,PR1,PR2). The key record from key record decrypt 
algorithm 718 is input to the hash algorithm 724, to produce the computed key authentication record (KAR), 
as described in step 515 of Fig. 17. Then the computed key authentication record (KAR) is input to a first 
side of the comparator 726. The second key record decrypt algorithm 720 uses the variant key KM + H2 to 
decrypt the encrypted key authentication record, as described in step 516 of Fig. 17, yielding the key 

45 authentication record KAR. Then the key authentication record KAR is input to a second side of the 
comparator 726. if the comparator 726 determines that the computed (KAR) is equal to the decrypted KAR, 
then an enabling signal "yes" is output to a control input of the gate 722, to pass the key record 
(parse,Ctl,PR1,PR2) from the first key record decrypt algorithm 718 to the key record register 728. 

The key record is input to the key record register 728 over line 18, with the parse data in a first 

so component register 730 and the concatenated control information Ctl, first private key PR1 and second 
private key PR2 in a second component register 732. The parse data in register 730 defines the beginning 
and ending of the control information Ctl, the first private key PR1 and the second private key PR2 in 
register 732. The parse data register 730 output is connected to a control input of the multiplexor 734, 
which separates the control information Ctl for output through register 736 to the public key algorithms 10 

55 and 10\ which separates the first private key PR1 for output through register 738 to the gate 742 and which 
separates the second private key PR2 for output through register 740 to the gate 744. 

Gate 742 has a control input connected to receive the Import DEA Key request signal R1, which 
enables the passing of the first private key PR1 to the first public key algorithm A1 at 10. The encrypted 
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DEA key ePU1(key1) which was encrypted under a first public key PU1, is input to the operand input of the 
first public key algorithm A1 . The control information Ctl input to the first public key algorithm A1 describes 
the key type for the first private key PR1 (i.e., specifies PR1 is a decryption key). Using the first private key 
PR1, the public key algorithm A1 at 10 decrypts the encrypted DEA key ePU1(key1), which was encrypted 

5 under a first public key PU1 , to obtain the clear text key 1 . 

Gate 744 has a control input connected to receive the Generate Digital Signature request signal R2, 
which enables the passing of the second private key PR2 to the second public key algorithm A2 at 10/. The 
clear text Data2 expression is input to the operand input of the second public key algorithm A2. The control 
information Ctl input to the second public key algorithm A2 describes the key type for the second private 

10 key PR2 (i.e., specifies PR2 is a decryption key). Using the second private key PR2, the public key 
algorithm A2 at 10' "decrypts" the clear text Data2 expression to obtain the requested digital signature. 

Alternate embodiments of the functional block diagram of Fig. 20 can include providing a single key - 
record decrypt algorithm which sequentially performs the functions of algorithms 718 and 720. Another 
alternate embodiment can include providing a single public key algorithm which sequentially performs the 

75 functions of algorithms 10 and 10'. Another alternate embodiment can include storing Key1 in a key block 
and receiving and processing the key in the encrypted form ePU1(key block). In that case, the output from 
public key algorithm A1 is a key block containing Key1. Another alternate embodiment eliminates the 
control information in the key record specifying that the key is a private key or a public key. Instead, the 
public key algorithms A1 and A2 include a control line indicating encryption or decryption, which is set by 

20 cryptographic facility 30 on the basis of the type of cryptographic operation requested. For example, for 
requests R1 and R2, cryptographic facility 30 will know that the key record contains a private key and that 
decryption with the private key is required. Thus, a decryption signal can be sent on the control line to the 
public key algorithms, A1 and A2. 

Key Tokens and Key Units: Thus far the described invention has taught that a key token is produced within 

25 the cryptographic facility (CF) 30 from a control vector and a key record, as shown in Fig. 21 , and the so- 
produced key tokens are stored outside CF 30 in a cryptographic key data set 32. Referring to Fig. 21 , a 
key record 401 and associated control vector 400 are stored either in an internal key token 403 or an 
external key token 404. That is, a key token is either an internal key token (also referred to as a key token, 
i.e., without the modifier 'internal 1 ) or an external key token. An Internal Key Token 403 consists of a header 

30 405, a control vector 406, and encrypted key record 407, and an encrypted authenticator 408. The 
encrypted key record 407 and encrypted authenticator record 408 are produced via key record encrypt 
algorithm 402, using as inputs control vector 400 and key record 401. Control vector 406 in internal key 
token 403 is just a copy of control vector 400, which is the control vector associated with key record 401. 
Key record encrypt algorithm 402 is the same key record encrypt algorithm 12 of Fig. 15. An External Key 

35 Token 404 consists of a header 409, a control vector 410, and a key record 411 (i.e., a clear key record). 
Control vector 410 in external key token 404 is just a copy of control vector 400, which is the control vector 
associated with key record 401. A key record is either a public key record (i.e., PU key record) or a private 
key record (i.e., PR key record). Likewise, an internal key token is either a internal PU key token or a 
interna! PR key token, depending on whether the key token contains a PU key record or a PR key record, 

40 respectively, and an external key token is either an external PU key token or an external PR key token, 
depending on whether the key token contains a PU key record or a PR key record, respectively. 

However, it may be advantageous to permit the cryptographic facility access program (CFAP) 34 to 
store key-related information in the key token, not directly available to the CF 30 and therefore not 
convenient or possible for the CF 30 to store in the key token. Thus, it may be more practical for the CFAP 
" 45 34 to add certain information fields to the key token once the key token is returned to the CFAP 34 as an 
instruction output. In such situations where the CFAP is permitted to add information to the key token, a 
new set of terminology is introduced, as illustrated in Fig. 22. Thus, the internal key token 403 in Fig. 21 
becomes internal key unit 423 in Fig. 22, and external key token 404 in Fig. 21 becomes external key unit 
435 in Fig. 22. Likewise, control vector 400, key record 401, and key record encrypt algorithm of Fig. 21 are 

so just control vector 420, key record 421, and key record encrypt algorithm 422 of Fig. 22. Likewise, header 
405, control 406, encrypted key record 407 and encrypted authenticator record 408 of Fig. 21 are just 
header 425, control vector 426, encrypted key record 427, and encrypted authenticator record 423 of Fig. 
22. Likewise header 409, control vector 410 and key record 411 of Fig. 21 are just header 429, control 
vector 430 and key record 431 of Rg. 22. Referring again to Hg. 22, internal key token 434 contains IKU 

55 423 as well as other data 432 supplied by CFAP 34. Likewise, external key token 435 contains EKU 424 as 
well as other data 433 supplied by CFAP 34. Where convenient, the terminology IKU (i.e., internal key unit) 
and EKU (i.e., external key unit) will be used in lieu of internal key token and external key token when it is 
necessary to refer to quantities produced by CF 30. 
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Public Key Cryptographic Design: Full features and apparatus of the invention, which is referred to herein as 
the Public Key Cryptographic Design (PKCD), are now described. The reader will appreciate that the 
methods used for key record encryption and decryption described earlier are essential for coupling the 
usage control to a key in a public key cryptosystem. The reader will also notice that although alternate 
5 embodiments have been discussed earlier for key record encryption and decryption, only the first 
embodiment of Fig. 16 and Fig. 17 is incorporated in the PKCD. 

COMPONENTS OF THE CRYPTOGRAPHIC FACILITY 

io The Cryptographic Facility contains three major components: 
o Instruction Processor 
o Cryptographic Algorithms 
o CF Environment 

75 INSTRUCTION PROCESSOR 

Fig. 23 is a block diagram illustration of the components of the Instruction Processor. They are: 
o INSTRUCTIONS: The CF instructions are invoked at the CFAP-To-CF interface. They provide the 

following cryptographic services to the CFAP: 
20 System Digital Signatures 

Application Digital Signatures 

Key Management 

CKDS Update 

CF Backup 
25 CF Audit 

CF Initialization 

CF Configuration 

CF Control 

Utility 

30 o INTERNAL ROUTINES: The internal routines are invoked only from within the CF. Collectively they 
represent a set of algorithms and processing functions that are common to many CF instructions. The 
internal routines have been specified to simplify the architectural description and definition, and to 
make each instruction's functional specification precise and less apt to contain errors and ambiguities. 
Although the internal routines are an integral part of the instruction functional specifications, an 

35 implementer may elect to implement the instructions and internal routines in a way that best suits or 

optimizes the particular implementation, 
o CONFIGURATION TABLE: The Configuration Table is a collection of constants that may vary in value 
from one implementation to another. The Configuration Table permits the Instructions and Internal 
Routines to be defined in a more general and open-ended way. Unlike the CF Environment, the 

40 Configuration Table is an integral part of the CF (e.g., hardware or ROS microcode). 

Fig. 24 is a block diagram illustration of the elements in the Configuration Table. 

CRYPTOGRAPHIC ALGORITHMS 

45 Fig. 25 is a block diagram illustration of the main components of Cryptographic Algorithms of the CF. 
The Cryptographic Algorithms components are these: 

o DATA ENCRYPTION ALGORITHM (DEA): The DEA is described in the American National Standards 
Institute (ANSI) Data Encryption Algorithm (DEA) X3.92-1981. The DEA is a symmetric algorithm 
which encrypts or decrypts a 64 bit input with a 64 bit key to produce a 64 bit output. The 64 bit key 

so specified to the algorithm consists of 56 key bits used by the algorithm and 8 non-key bits, which 

optionally may be used for error detection. According to ANSI X3.92-1981, the 8 non-key bits MAY be 
used for error detection.. On the other hand, according to FIPS PUB 46, the 8 non-key bits SHALL be 
used for error detection and more specifically the error detection is based on byte-by-byte odd parity. 
Although the Symmetric Key Cryptographic Algorithm can be an optional component of the Cryp- 

55 tographic algorithms 144 shown in Fig. 15, the DEA is a required component in the PKCD, as it is 

needed for key record encryption and decryption, 
o PUBLIC KEY ALGORITHM (PKA): PKA is a generic term referring to one of several possible public 
key algorithms. The PKCD does not specify the use of a particular PKA. However, the PKA must 
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permit key distribution to be based on a key server concept wherein a DEA key, randomly generated 
and encrypted with a public key of a receiving device, is served to a receiving device where it is 
decrypted with the private key of the receiving device and reencrypted under the master key. The 
PKA must also permit generation and verification of digital signatures. A digital signature is produced 
5 by decrypting a signature record, containing a hash value, with a private key. A digital signature is 

verified by encrypting the signature with a public key and comparing hash values. The PKCD also 
permits key distribution with a first PKA and digital signatures to be implemented with a second PKA. 
o PUBLIC KEY ALGORITHM KEY GENERATOR (PKAKG): PKAKG is a separate algorithm for the 
generation of keys used by the PKA. 
10 Besides the main components, there are lower level algorithms, such as Key Record Encryption and 
Key Record Decryption algorithms needed for frequent encryption and decryption of public and private 
keys, as discussed earlier. 

CF ENVIRONMENT 

75 

Fig. 26 is a block diagram illustration of the components of the CF Environment. 
The CF Environment components are these: 

o CONFIGURATION VECTOR: The configuration vector is a collection of encoded fields that limit or 

restrict the operation of the cryptographic facility. The configuration vector is set to a default value via 
20 execution of the Enter Initialization State (EIS) instruction, or it may be set to an installation-specified 

value via execution of the Load Configuration Vector (LCV) instruction, 
o STATE VECTOR: The state vector is a collection of flags and state variables that define the current 

state of the cryptographic facility. The state vector is used by the instruction processor to control the 

order in which PKCD instructions are executed. 
25 o REGISTERS: The registers contain space for the storage PKCD cryptovariables, including keys, MDC 

values, internal counters, identifiers, and control vectors, 
o MDC TABLE: The MDC table contains space for the storage of Modification Detection Codes (MDCs) 

used by the Import Public Key (IPUK) instruction to import External Key Units. Each table entry is an 

MDC calculated on an External Key Unit using a hash algorithm. 
30 o COUNTER TABLE: The Counter table contains space for the storage of counters, where each counter 

is associated with a particular PKCD instruction. Counter(i) contains a value n n" from 1 to 255, set by 

the SEF instruction, which represents the number of times instruction n i n is permitted to be executed, 
o CFPKR1 -LENGTH: The length of cfpkrl in 8-byte blocks, cfpkrl is stored in the PUA Buffer and 

contains the Public Device Authentication Key (PUA). 
35 o PUA BUFFER: The PUA buffer contains space for the storage of cfpkrl , which contains PUA. The 

PUA buffer is used only by the PKCD instructions, 
o CFPKR2-LENGTH: The length of cfpkr2 in 8-byte blocks. cfpkr2 is stored in the PRA Buffer and 

contains the Private Device Authentication key (PRA). 
o PRA BUFFER: The PRA buffer contains space for the storage of cfpkr2, which contains PRA. The 
AO PRA buffer is used only by the PKCD instructions. 

o SECRET PRODUCT ENVIRONMENT LENGTH: The length of the secret product environment in 

bytes. 

o SECRET PRODUCT ENVIRONMENT: The secret product environment consists of a set of the secret 
cryptographic variables unique to a product or implementation. That is, secret cryptographic variables 
45 not specified by PKCD but needed by a product. 

o NONSECRET PRODUCT ENVIRONMENT LENGTH: The length of the nonsecret product environment 
in bytes. 

o NONSECRET PRODUCT ENVIRONMENT: The nonsecret product environment consists of a set of 
the nonsecret cryptographic variables unique to a product or implementation. That is, nonsecret 
so cryptographic variables not specified by PKCD but needed by a product, 

o EKU LENGTH: The length in bytes of the EKU in the EKU buffer. 

o EKU BUFFER: A buffer for the temporary storage of an External Key Unit (EKU) (e.g., an EKU loaded 

into the CF via an interface other than the CFAP-to-CF interface), 
o GKSP SAVE: A field used by process-mode = 1 of the Generate Key Set Pair (GKSP) instruction to 
55 save information needed by process-mode = 2 of the GKSP instruction, 

o GKSP BUFFER LENGTH: The length of GKSP Buffer in bytes, 
o GKSP RECORD LENGTH: The length of record or block in GKSP Buffer in bits, 
o GKSP BUFFER FLAG: A flag indicating the status of the record or block in GKSP Buffer, as follows: 
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- 4-255 : reserved 

- 3 : GKSP Buffer contains a record of unspecified format that must be processed to produce a 
keyblk which is then encrypted. 

- 2 : GKSP Buffer contains a keyblk of unspecified format that needs only to be encrypted. 
5 - 1 : GKSP Buffer contains a CF DEA Key Record. 

- 0 : GKSP Buffer is empty 

o GKSP TICKET: An 8-byte pseudorandom value generated via execution of process-mode = 1 of the 
GKSP instruction. 

o GKSP BUFFER: A buffer for the storage of a key record or key block. 
70 o IDK SAVE: A field used by process-mode = 1 of the Import DEA Key (IDK) instruction to save 
information needed by process-mode = 2 of the IDK instruction. 

o IDK BUFFER LENGTH: The length of IDK Buffer in bytes. 

o IDK RECORD LENGTH: The length of record or block in IDK Buffer in bits. 

o IDK BUFFER FLAG: A flag indicating the status of the record or block in IDK Buffer, as follows: 
75 - 4-255 : reserved 

- 3 : IDK Buffer contains a record of unspecified format recovered from a keyblk of specified format 
recovered by process-mode = 1 of the IDK instruction by decrypting ePUM(keyblk). 

- 2 : IDK Buffer contains a keyblk of unspecified format recovered by process-mode = t of the IDK 
instruction by decrypting ePUM(keyblk). 

20 - 1 : IDK Buffer contains a CF DEA Key Record. 

- 0 : IDK Buffer is empty 

o IDK TICKET: An 8-byte pseudorandom value generated via execution of process-mode = 1 of the IDK 
instruction. 

o IDK BUFFER: A buffer for the storage of a key record or key block. 

25 

CONFIGURATION VECTOR 

The configuration vector has the following specification: 
30 CONFIGURATION VECTOR: 
bits 

00.. 07 Version Number 

35 

X'00' : reserved 
X'OV : PKCD 
X'lO-XTF: reserved 

40 08..151 DEFINE field 

The DEFINE field is a vector indexed as DEFINE(i) for i = 0,1 ,...,143. 
For i = 0,109 DEFINE(i) is reserved. 

For i = 11 0,1 11,. ..,143 DEFINE(i) pertains to the instructions of the PKCD. 

45 DEFINE(i) for i = 110 143 has the following meaning: 

BT : instruction is defined to the CF in the "run" state 
B'0' : instruction is not defined to CF in the "run" state 

Note: DEFINE(i) for i = 110.....143 pertains only to execution of instructions in the "run" state. 
A list of the instructions and their corresponding indices are provided in Fig. 27. 

50 

152..295 AUTH CONTROL field 

The AUTH CONTROL field is a vector indexed as AUTH CONTROL(i) for i = 0,1, ...,143. 
For i =0,1, .,.,109 AUTH CONTROL(i) is reserved. 
55 For i = 110, ...,143 AUTH CONTROL(i) pertains to the instructions of PKCD. 
AUTH CONTROL(i) has the following meaning: 

B'V : the LCV instruction sets AUTH(i) = BT and ENABLE(i) = B'lV (i.e., "authorization required" 
& "disabled"). 
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B'O' : the LCV instruction sets AUTH(i) = B'O' and ENABLE(i) = BW (i.e., "authorization not 
required" & "enabled"). 
A list of the instructions and their corresponding indices are provided in Fig. 27. 

5 296 CERTIFICATION 

BT : certification center (the device can act as a certification center) 

B'O/ : not a certification center (the device cannot act as a certification center). This means the 
following: Generate Public and Private Key Pair (GPUPR) cannot generate a certification key 
w pair; a PRC key cannot be used with the Generate Digital Signature (GDS), Generate 

Application Digital Signature (GADS), and/or Export Public Key (EPUK) instructions to generate 
a digital signature. 



75 



20 



297 KMP RELOAD 

BT : if CKMP HISTORY in state vector = 0, then KMP-mode = 1 must be specified in the ECFER 
instruction (i.e., the PKA Key Encrypting Master Key (KMP) must be reloaded at the receiving 
device). 

B'0' : no restrictions Note that this field pertains only to the ECFER instruction. 

298 KM RELOAD 



B'V : (reserved for future use) if CKM HISTORY in state vector = 0, then KM-mode = 1 must be 
specified in the ECFER instruction (i.e., the DEA key encrypting master key KM must be 
25 reloaded at the receiving device). 

B'O* : no restrictions Note: this field pertains only to the ECFER instruction. Note: the LCV instruction 
sets this bit = B'O 1 , which guarantees that present systems shall be compatible with future 
releases implementing the KM RELOAD bit. 

30 299..300 FLOOR-MDC field 

The FLOOR-MDC field specifies the following: 

a. The minimum THRES-MDC value that may be specified in the PRM control vector in the GPUPR 
instruction. 

35 b. The minimum HIST-MDC value in the PUA control vector that can be processed by the ECFER and 

ICFER instructions. 
The FLOOR-MDC field has the following meaning: 

B'1V : The referenced THRES-MDC or HIST-MDC must have a value = BM1. 

B'lO* : The referenced THRES-MDC or HIST-MDC must have a value £ B'10. 
40 B'OV : The referenced THRES-MDC or HIST-MDC must have a value £ B'01. 

BW : reserved 

Note that the FLOOR-MDC field controls the processing of PU keys in the GPUPR, ECFER, and ICFER 
instructions. 

45 301 ..302 KMGT PROTOCOL (i.e., key management protocol via the GKSP and IDK instructions). 

B'11*: CKMGT & PKMGT (i.e., certification center and private key management protocols are 
enabled). 

B'10' : CKMGT (i.e., certification center key management protocol is enabled) 
so B'OV : PKMGT (i.e., private key management protocol is enabled) 
B'00' : none 
Notes: 

a) KMGT PROTOCOL = B'lV means that the key-management-protocol parameter in the GKSP and 
IDK instructions may be 0 or 1. 
55 b) KMGT PROTOCOL = BMO* means that the key-management-protocol parameter in the GKSP and 
IDK instructions may only be 1. 

c) KMGT PROTOCOL = B'OV means that the key-management-protocol parameter in the GKSP and 
IDK instructions may only be 0. 
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d) KMGT PROTOCOL = BW means that key management via the GKSP and IDK instructions is not 
permitted. 

303..304 BKUP PROTOCOL (i.e., protocol for CF-environment backup via the ECFER and ICFER instruc- 
5 tions). 

B'11* : PBKUP (private protocol, i.e., no restriction on how PUA is imported) 
B'KV : CBKUP2 (certification center protocol where the PUA control vector has HIST-CHAIN = 3) 
B f 0T : CBKUP1 (certification center protocol where the PUA control vector has HIST-CHAIN = 2) 
w BW : no backup permitted 

Note that the specification matches that of the protocol-mode parameter in the ECFER and ICFER 

instructions. 

The BKUP PROTOCOL field is valid only when DEFINE(ECFER) = BT or DEFINE(ICFER) = BT. 
15 305 KREG field 

The KREG field defines the key registration mode or modes permitted for certification center key 
management and for certification center backup, as follows: 
1 : restricted mode 
20 0 : unrestricted mode 

Note: the meanings attached to restricted mode and unrestricted mode are specified by the network, i.e., 
set forth according to network security policy. 

For example, the certification center could define restricted mode such that the conditions in (a) or (b) must 
be satisfied, as follows: 

25 (a) PUM key registration is performed in a physically secure environment; KMP is loaded into the device 
by trusted personnel using the LFPMKP and CPMKP instructions or KMP is internally generated using 
the GNPMK instruction. 

(b) PUM key registration is not performed in a physically secure environment, but the External Key Unit 
containing PUM (sent to the certification center for registration) is signed with a PRA key which has been 
30 independently validated by the certification center as originating from within the said device. KMP is 
internally generated using the GNPMK instruction. 
Both (a) and (b) represent very 'high security 1 modes. 
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306 INTERCHANGE 

BT : interchange (the device can act as an interchange device) A PRA, PRM, and PRU key can be 

used with the GDS instruction to generate digital signatures. 
B'O" : not interchange (the device cannot act as an interchange device). A PRA, PRM, and PRU key 

cannot be used with the GDS instruction to generate digital signatures. 

307..308 SIG-COMPATIBILITY field 



The SIG-COMPATIBILITY field is a vector indexed as COMPATIBILITY(i) for i = 0 and 1. 
For i = 0, SIG-COMPATIBILITY(i) pertains to the IPUK instruction. 
45 For i = 1, SIG-COMPATIBILITY(i) pertains to the IDK instruction. 
SlG-COMPATIBILITY(i) has the following meaning: 

BT : the instruction does not require CF authentication of system signatures. 

B'O' : the instruction requires CF authentication of system signatures. 

so 309..51 1 reserved, set : = 203 B'0'. 

DEFAULT CONFIGURATION VECTOR 

The default configuration vector is the value of the configuration vector automatically set via execution 
55 of an EIS instruction. The value of the default configuration vector in 8 groups of 16 hexadecimal digits per 
group is as follows: 

1 . X'01 FFFFFFFFFFFFFF* 

2. XTFFF0000000003FP 
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3. XTFFFFF000OOOO0O0* 

4. X'OOOOOOOOOOOOOOOO' 

5. X'OOOOOOOOOOOEOOOCr 

6. X , 0000000000000000 l 

7. X^OOOOOOOOOOOOOOO' 

8. X'OOOOOOOOOOOOOOOO 1 

The default configuration vector has the following specification: 
DEFAULT CONFIGURATION VECTOR: 



bits value field 
00.. 07 (= B'OOOOOOOl' ) Version Number 
08.. 151 DEFINE 
08.. 79 (= 72 B'l') Reserved 
80.. 117 (= 38 B'O 1 ) reserved 
118. .151 (= 34 B'l') PKCD instructions (VADS thru 

VIKU) 

152. .295 (= 144 B'O 1 ) AUTH CONTROL 

296 (= B'O 1 ) CERTIFICATION (not certification 

center) 

297 (= B'O') KMP RELOAD (no restrictions) 

298 (= B'O') KM RELOAD (no restrictions) 
299.. 300 (= B'01') FLOOR-MDC field (The referenced 

THRES-MDC 

or HIST-MDC must have a value 
> B'01' .) 

301.. 302 (= B* 11 1 ) KMGT PROTOCOL (CKMGT and PKMGT 

modes ) 

303. .304 (= B'00') BKUP PROTOCOL (backup not 

permitted) 



305 (= B'O') KREG field (unrestricted mode) 

306 (= B'0 f ) INTERCHANGE (not an interchange) 

307 (=B'0') SIG-COMPATIBILITY(IPUK) 

(signature required) 

308 (= B'0') SIG-COMPATIBILITY(IDK) (signa- 

ture required) 
309.. 511 (= 203 B'0') reserved 



STATE VECTOR 

The state vector has the following specification: 
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STATE VECTOR: 

00 KP FLAG (Key Part) 

5 BT : the KP register is in the "full" state 

B'O' : the KP register is in the "empty" state 

01 OKM FLAG (Old DEA key encrypting master key) 

/o BT : the OKM register is in the "full" state 

B'O 1 : the OKM register is in the "empty" state 
Note: In a subsequent release of PKCD, the existing OKM flag shall be reimplemented within the state - 
vector. For the present, this field is initialized only via the EC FAR instruction (thus making it appear that the 
OKM flag is implemented within the state vector). 

15 

02 CKM FLAG (Current DEA key encrypting master key) 

BT : the CKM register is in the "full" state 
B'O' : the CKM register is in the "empty" state 
20 Note: In a subsequent release of PKCD, the existing CKM flag shall be reimplemented within the state 
vector. For the present, this field is initialized only via the ECFAR instruction (thus making it appear that the 
CKM flag is implemented within the state vector). 

03.. 04 NKM FLAG (New DEA key encrypting master key) 

25 

B'1V: reserved 

B'10' : the NKM register is in the "full" state 
B'OV : the NKM register is in the "partially full" state 
BW : the NKM register is in the "empty" state 
30 Note: In a subsequent release of PKCD, the existing NKM flag shall be reimplemented within the state 
vector. For the present, this field is initialized only via the ECFAR instruction (thus making it appear that the 
NKM flag is implemented within the state vector). 

05 Reserved 

35 

06.. 12 RESERVED (= 7B'0') 

13 PROG FLAG 

40 BT : An executable program has been loaded 

B'O' : An executable program has not been loaded 

14 PROGMDCO FLAG (Secure loadable program MDC #0) 

45 B f 1 1 : PROGMDCO buffer is in the "full" state 

B'O' : PROGMDCO buffer is in the "empty" state 

15 PROGMDC1 FLAG (Secure loadable program MDC #1) 

50 B'V : PROGMDC1 buffer is in the "full" state 

B'O' : PROGMDC1 buffer is in the "empty" state 

16.. 21 KM HISTORY field 

55 The KM HISTORY field is a vector indexed as KM HISTORY(i) for i = 0,1,2, where i is defined as: 

0 : OKM 

1 : CKM 
2 : NKM 
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KM HISTORY(i) has the following meaning: 
B'1V: reserved 

B'10' : (reserved) GNDMK (i.e., the contents of the KM register were produced via execution of the 
GNDMK instruction). 

5 B'OT : (reserved) LFMKP/CMKP (i.e., the contents of the KM register were produced via execution 
of the LFMKP and CMKP instructions). 
B'00' : indeterminate 

Note: The EPS instruction sets this field to B'OOOOOO*, ensuring the present PKCD will be compatible with 
future releases of PKCD implementing code points B'OV and B'10 1 of the KM HISTORY field. 
70 Note: In a subsequent release of PKCD, the SMK instruction shall be modified so that the OKM HISTORY 
field is updated from the CKM HISTORY field. 

Note: In a subsequent release of PKCD, the SMK instruction shall be modified so that the CKM HISTORY 
field is updated using a method which is similar to that followed by the SPMK instruction in its management 
of the CKMP HISTORY field. The SMK instruction shall also be modified so that the CKM HISTORY field is 
75 reset to the "indeterminate" state whenever the CKM FLAG is reset to the "empty" state, and the NKM 
HISTORY field is reset to the "indeterminate" state whenever the NKM FLAG is reset to the "empty" state. 
Note: In a subsequent release of PKCD, the GNDMK instruction shall be modified to reset the NKM 
HISTORY field to B'10\ and the LFMKP and CMKP instructions shall be modified to reset the NKM 
HISTORY field to B'OV. 
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The AUTH field is a vector indexed as AUTH(i) for i = 0,1 ,...143. 
For i = 0,1, ...,109 AUTH(i) is reserved 
25 For i = 110, ...,143 AUTH(i) pertains to instructions of the PKCD. 
AUTH(i) has the following meaning: 

BT : the SEF instruction can be used to enable execution of instruction or instruction mode V only 
after supplying appropriate proof of authorization to the CF. The level of authorization is 
determined by the implementation and can be different for each "i." 
30 B'0' : no restrictions 

AUTH(i) is not defined for the following instructions: 

(1) LPID, GDAK, LCV, since they do not execute in the "run" state. 

(2) ERS, since the specification is contradictory. 

(3) SEF, since this could lead to "lockout." 

35 A list of the instructions and their corresponding indices are provided in Fig. 27. 



166..453 ENABLE field 



The ENABLE field is a vector indexed as AUTH(i) for i = 0,1 ,...143. 
40 For i = 0,1, ...,109 ENABLE(i) is reserved 

For i = 110 143 ENABLE(i) pertains to instructions of the PKCD. 

ENABLE(i) has the following meaning: 

B'11' : instruction or instruction mode execution not enabled. 

B'10' : instruction or instruction mode enabled for n executions, where n (a value from 1 to 255) is a 
45 value specified by an instruction input parameter. . . 

B'OV : instruction or instruction mode enabled for 1 execution. 
B'00' : instruction or instruction mode enabled for any number of executions. 
ENABLE(i) = B'00' and ENABLE = B'1V are valid for all but the following instructions: 
(1) LPID, GDAK, LCV, since they do not execute in the "run" state, 
so (2) ERS, since the specification is contradictory. 
(3) SEF, since this could lead to "lockout." 
ENABLE(i) = B'10' is valid only for the following instructions: 

(1) CPMKP input-mode = 0 and CPMKP input-mode = 1 

(2) GPUPR mode = 0/2. 

55 ENABLE(i) = B'OV is valid only for the following instructions: 

(1) LMDCC 

(2) LMDC 

(3) LFPMK input-mode = 0 and LFPMK input-mode = 1 
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(7) GNPMK, 

(8) GNDMK, 

(9) SPMK, 

(10) ECFER 

5 A list of the instructions and their corresponding indices is provided in Fig. 27. 

454 CLONE (history bit) 

BT : CF-environment has been set via the ICFER instruction. 
to B'O' : original CF-environment 

Note: this bit is reset to 0 via execution of an EPS instruction but not by an EIS instruction. This bit is set to 
BT via execution of the ICFER instruction. 

455..457 KMP-HISTORY field 
75 The KMP-HISTORY field is a vector indexed as KMP-HISTORY(i) for i = 0,1,2, where i is defined as: 

0 : OKMP HISTORY 

1 : CKMP HISTORY 

2 : NKMP HISTORY 

20 KMP stands for PKA Key encrypting Master key. 
KMP-HISTORY(i) has the following meaning: 

BT : GNPMK (i.e., the contents of the KMP register were produced via execution of the GNPMK 
instruction). 

B'O' : LFPKMP/CPMKP (i.e., the contents of the KMP register were produced via execution of the 
25 LFPKMP and CPMKP instructions). 

Note: KMP-HISTORY(i) has meaning only when KMP- FLAG (i) is in the "full" state. 

458..461 KMP-FLAG field 

30 The KMP-FLAG field is a vector indexed as KMP-FLAG(i) for i = 0,1 ,2, where i is defined as: 

0 : OKMP FLAG 

1 : CKMP FLAG 

2 : NKMP FLAG 

For i = 0 and 1, KMP-FLAG(i) is a 1 bit field with the following meaning: 

35 BT : the KMP register is in the "full" state 

B'O' : the KMP register is in the "empty" state 
For i = 2, KMP-FLAG(i) is a 2 bit field with the following meaning: 

B'11': reserved 

B'10' : the KMP register is in the "full" state 

40 B'01': the KMP register is in the "partially full" state 

BW : the KMP register is in the "empty" state 

462 GDAK FLAG 

45 BT : the PUA buffer, PRA buffer, PUACV register, and PRACV register are in the "full" state. 

B*0* : the PUA buffer, PRA buffer, PUACV register, and PRACV register are in the "empty" state. 

463 LPID FLAG 

so BT : the DID and EID registers are in the "full" state. 

B*0* : the DID and EID registers are in the "empty" state. 

464 LCV FLAG 

55 BT : a configuration vector has been loaded using an LCV instruction. 

B'O* : a configuration vector has not been loaded using an LCV instruction. 
If CF STATE = "init" or "run", then CONFIG FLAG = B'O' indicates that a default configuration vector has 
been loaded. 
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75 



40 



45 



55 



465 EKU FLAG 

BT : an EKU is stored in the EKU buffer and its length is stored in EKU Length. 

B'0* : an EKU is not stored in the EKU buffer and its length is not stored in EKU Length. 

466..4S7 CF STATE 



B'1V 
B'10' 
io B'OT 
B*00' 



reserved 

the CF is in the "run" state 
the CF is in the "init" state 
the CF is in the "pre-init" state 



Note: the CF states control instruction execution. 

468..501 EKUMDC FLAG field 

The EKUMDC FLAG field is a vector indexed as EKUMDC FLAG(i) for i = 0,1, ...,16. 
For i = 0,1 ,...,15, EKUMDC FLAG(i) has the following meaning: 

B'11' : EKUMDC(i) has been initialized with an MDC loaded via a secure interface (e.g., via a smart 
card). 

20 B'10' : EKUMDC(i) has been initialized with the LMDCC instruction. 

B'OV : EKUMDC(i) has been initialized via the IPUK instruction. 

B'OO' : EKUMDC(i) is uninitialized. 
For i = 16, EKUMDC FLAG(16) has the following meaning: 

B'1V : EKUMDC(16) has been initialized with an MDC loaded via a secure interface (e.g., via a smart 
25 card). 

B'10' : EKUMDC(16) has been initialized via an LMDC instruction. 

B'OV : reserved 

BW : EKUMDC(16) is uninitialized. 

30 502 PR HISTORY 

BT : one or more PR have not been randomly generated inside the CF. 
B'O' : all PR have been randomly generated inside the CF. 

35 503 ECFER Status 

BT : the ECFER instruction has been executed at least once (i.e., the CF environment of this device 

has been exported). 
B'0' : the ECFER instruction has not been executed. 



504 ALARM FLAG 

BT : Alarm has been activated 
B'0' : no Alarm 

505..508 HIST-DOMAIN 



This field contains a domain identifier (an arbitrary value from B'0000' to EH 11V). The HIST-DOMAIN field 
in the state vector is set by the ECFER instruction equal to the value of DOMAIN ID in the HIST-DOMAIN 
50 field of the PUA control vector contained in IKU1, which is input to the ECFER instruction. 

This field is valid only if the CLONE bit in the state vector is equal to BT and BKUP PROTOCOL in the 
configuration vector is equal to B*0V (CBKUP1) or B'10' (CBKUP2). 



509..511 reserved, set = 3 B'0\ 
REGISTERS 

The following registers are defined by PKCD: 
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NKMP Register 


S I 


128b 


CKMP Register 


P I 


128b 


OKMP Register 


P 


128b 


DID Register 


P 


128b 


EID Register 


P 


128b 


PUACV Register 


P 


128b 


PRACV Register 


P 


128b 









New PKA Master Key Register 
Current PKA Master Key Register 
Old PKA Master Key Register 
Device Identifier Register 
Environment Identifier Register 
PUA Control Vector 
PRA Control Vector 



The registers are designated as permanent (encoded with letter "P") or semi-permanent (encoded with 
letter "S"). The contents of the permanent registers must be preserved for the "life of the system," e.g., via 
a battery-backed RAM. Values stored in the permanent registers change or are changed according to an 
installation-determined schedule. The contents of the semipermanent registers must be preserved only until 
the information they contain has been processed by a CF instruction. 

MDC TABLE 

The MDC Table is a vector EKUMDC(i), for i = 0,1,. ..,16, where each EKUMDC(i) contains storage for a 
128 bit MDC value. 

Fig. 28 illustrates the organization and indexing of the MDC Table. 

The MDC Table is used by the IPUK instruction to import public keys, which are presented to the IPUK 
instruction in the form of an External Key Unit (EKU). For i = 0,...,15, the MDC in EKUMDC(i) must be 
calculated on an EKU containing a public certification key (i.e., a PUC key) and the domain ID field in the 
control vector of the PUC key must contain the value V. For i = 16, the MDC in EKUMDC(i) must be 
calculated on a EKU containing a public key management key, a public authentication key, or a public user 
key (i.e., a PUM, PUA, or PUU key). The domain ID field can contain any value from 0 to 15. 

COUNTER TABLE 

The Counter Table is a vector COUNTER(i), for i = 0,1 143, where each COUNTER(i) contains 

storage for an 8 bit counter. For i = 113, 114, or 120, COUNTER(i) is defined. For i * 113, 114, or 120, 
COUNTER(i) is not defined (i.e., this portion of Counter Table is null). 

The value of COUNTER(i) denotes the number of times that instruction "i" can be executed before 
ENABLE(i) is set from B*10' to B'11\ Fig. 27 specifies the relationship between index and instruction name. 
For example, i = 113 denotes input-mode = 0 of the CPMKP instruction. 

Fig. 29 illustrates the organization and indexing of the Counter Table. 

CONTROL VECTOR ENFORCEMENT 

Control vector enforcement is a method which ensures that the control vectors processed by each CF 
instruction are consistent with and in conformance with certain instruction-unique rules and restrictions 
which limit or define the values that these control vectors may have. Control vector enforcement may be 
accomplished by, although is not limited to, one of the following methods or combinations thereof: 
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o SPECIFY CONTROL VECTOR IN CFAP AND CHECK CONTROL VECTOR BITS IN CF: This method 
checks bits and fields within the control vector to ensure that they contain permitted values. In certain 
cases, cross checking of bits and fields among two or more control vectors is necessary to ensure 
that they contain only permitted combinations of values. 
5 o SPECIFY CONTROL VECTOR IN CFAP AND SET CONTROL VECTOR BITS IN CF: This method 
sets bits and fields within the control vector to prescribed values (i.e., by overwriting the bits and 
fields of the control vectors passed at the instruction interface), 
o GENERATE CONTROL VECTOR IN CF FROM INFORMATION SPECIFIED BY CFAP: This method 
generates control vectors from parameter information passed at the instruction interface. 
w o TABLE LOOKUP OF CONTROL VECTOR IN CF FROM INDEX SPECIFIED BY CFAP: This method 
uses a table of control vectors stored within the CF. An index value passed at the instruction interface 
selects the control vector or vectors used by an instruction. 
For convenience, control vector enforcement is defined in this teaching using a combination of the first 
and third methods described above. Some control vectors are specified as instruction parameters and bits 
75 and fields in these control vectors are checked by the CF. Other control vectors are generated within the 
CF, e.g., it is typical for the control vector associated with the rightmost 64 bits of a 128 bit key to be 
derived from the control vector associated with the leftmost 64 bits of a 128 bit key. 

INITIALIZATION REQUIREMENTS 

20 

Some CF instructions process cryptovariables stored internally within the CF, which must be loaded or 
imported into the CF before instruction execution. Several CF instructions have been defined to support the 
initialization and configuration of the CF. However, PKCD does not define or specify how key parts are 
loaded into the KP register. 

25 Those CF instructions which process cryptovariables stored in the KP register, which must be loaded 
via means other than those defined in the PKCD, are listed in the following table. 



Instruction 


Cryptovariable 


CF Storage Location 


LFPMKP 
CPMKP 


key part 
key part 


KP register 
KP register 



PKCD do not define how key parts are loaded into the KP register. One possibility is for key parts to be 
loaded by authorized installation personnel via a protected, controlled interface. The physical interface 
described earlier could be used for this purpose. 

POWER ON SEQUENCE 

During each power-on, the CF executes a power-on sequence (POS) routine. The POS routine does the 
following: 

o Initialize the PRNGKEY1 and PRNGKEY2 registers with random seed keys. 

o If the content of the POS register = )C0123456789ABCDEF0123456789ABCDEF then continue; else 
do the following: 

- Perform the EIS instruction to clear the CF environment. 

- Set POS register := X , 0123456789ABCDEF0123456789ABCDEF\ 
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RECORD FORMATS AND DESCRIPTIONS 

The following records are defined by PKCD: 



Record Name 


Length 


Crypto Facility PKA Key Record 


multiple of 8 bytes 


Crypto Facil.Key Authentlcator Record 


multiple of 8 bytes 


Crypto Facility DEA Key Record 


64 bytes 


Crypto Facility Backup DEA Key Record 


64 bytes 


Crypto Facil.System Signature Record 


64 bytes 


Crypto Facility Environment Record 


multiple of 8 bytes 


Crypto Facility Audit Record 


multiple of 8 bytes 


Internal Key Unit 


multiple of 8 bytes 


Clear Key Unit 


multiple of 8 bytes 


External Key Unit 


multiple of 8 bytes 


Skeleton Key Unit 


multiple of 8 bytes 



CRYPTO FACILITY PKA KEY RECORD (CFPKR) 

The Crypto Facility PKA Key Record (CFPKR) contains a public or private key used with a public key 
algorithm. If different public key algorithms are used for key distribution and digital signatures, then the 
CFPKR contains two public or two private keys-one key for key distribution and the other for digital 
signatures. The CFPKR is defined to be a multiple of 8 bytes. 

A Crypto Facility PKA Key Record has the following form: 



Offset 


Length 


Data 


(in bits) 


0 


a 


Parse 


a 


b 


Key 


c 


d 


RN (where c = a + b) 


e 


0 


End of CFPKR (where e = c + d) 
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DATA 



DESCRIPTION 



PARSE 



10 



75 



20 



25 



30 



35 



KEY 



RN 



The parse field contains data that permits the CF to 
parse the key field. The length of the key parse field is 
not prescribed by the architecture. The key parse field 
MUST permit the key, or any portion of the key, to be 
uniquely identified and located in the key field. The 
parse field must directly or indirectly specify key 
length, such that an adversary cannot cause the CF to 
use only a portion of a key as a full key. In addition, the 
parse field contains at least 8 bytes of random data to 
act as a confounder to thwart revealing any contents of 
the encrypted CFPKR by pattern analysis by an 
adversary. 

The key field contains a PKA key. The key is either a 
public key or a private key. The key stored in the key 
field consists of one or more key variables that 
together constitute or define the key. For example, if 
the PKA is based on exponentiation modulo a number 
n, then the key consists of an exponent e and a 
modulus n. Both e and n are stored in the key field, 
and the parse field is defined in such a way to permit e 
and n to be located. Key length and format of the parse 
and key fields can be different depending on whether 
the key is a public key or a private key. If a first PKA is 
used for key distribution and a second PKA is used for 
digital signatures, then the Key field contains a pair of 
public or private keys (i.e., a key for each algorithm). 
The fact that there are two algorithms is made 
transparent to the CFAP. 
The RN field contains a d-bit random number 
generated within the CF. The value d ranges from 0 to 
63 and is chosen so that the length of CFPKB is a 
multiple of 8 bytes. 



Outside the CF, the CFPKR is encrypted under a variant key KMP.C formed as the Exclusive OR 
product of KMP and control vector C. 



CRYPTO FACILITY KEY AUTHENTICATOR RECORD (CFKAR) 

The Crypto Facility Key Authenticator Record (CFKAR) contains information functionally related to a 
single CFPKR. The CFKAR is used to authenticate a CFPKR. The CFKAR is defined to be a multiple of 8 
bytes. 

A Crypto Facility Key Authenticator Record has the following form: 



Offset 


Length 


Data 


(in bits) 


0 


a 


Key Authenticator 


a 


b 


RN 


c 


0 


End of CFPKR (where c = a + b) 
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DATA 


DESCRIPTION 


KEY AUTH ENTICATOR 
RN 


The key authenticate* field contains data functionally related 
to a CFPKR. 

The RN field contains a b-bit random number generated 
within the CF. The value b ranges from 0 to 63 and is 
chosen so that the length of CFKAR is a multiple of 8 bytes. 



Outside the CF, the CFKAR is encrypted under a variant key KMP.C formed as the Exclusive OR 
product of KMP and control vector C. 

Methods for deriving a key authenticator from a key record has been discussed in Key Record Encrypt 

Algorithm 12 of Fig. 16. 

CRYPTO FACILITY DEA KEY RECORD (CFDKR) 

The Crypto Facility DEA Key Record is produced by a GKSP instruction and is processed by an IDK 
instruction. The CFDKR is a 52 byte record. 

A Crypto Facility DEA Key Record has the following form: 
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Offset Length Data 
(in bytes) 



10 



20 



30 



35 



45 



0 1 Record ID 
The most significant bit in a byte is the leftmost bit. 
0000 0000 - 'Crypto Facility DEA Key Record* 

1 1 Record Code 

000 xxxxx - 128b key-encrypting key produced by GKSP and 
processed by IDK. 

When bits 0..2 of the above field are B'OOO 1 , 
75 bits 3. ,7 are defined as follows: 

Control Vector Format 

000 xxxOO - control vector field stores hash of 128 bit C. 
000 xxxOl - control vector field stores hash of 64 bit C. 
000 xxxlx - reserved 
KEY -MANAGEMENT-PROTOCOL specified in GKSP (implying IDK 
must also specify the same) 
25 000 Oxxxx - private protocol 

000 lxxxx - certification center protocol 

KEY-MANAGEMENT-MODE specified in GKSP (implying IDK must 
also specify the same) 

000 xOxxx - key registration is performed using mode 0 
000 xlxxx - key registration is performed using mode 1 



001 xxxxx - reserved 
Olx xxxxx - reserved 
lxx xxxxx - reserved 
2 2 Reserved (^'OOOO*) 

40 4 16 EID - The value of EID stored in the CF Environment of 

the originating device. 
20 16 h(C), where C is a 64- or 128-bit control vector and 

h is a hash function. Basically, if C is 64 bite, then 
h(C) = concat(C,C). And, if C is 128 bits, then h(C) - C. 
36 16 Key - This field contains a 128 bit odd parity adjusted 

key generated within the CF by the GKSP instruction, 

50 

CRYPTO FACILITY BACKUP DEA KEY RECORD (CFBDKR) 

The Crypto Facility Backup DEA Key Record is produced by an ECFER instruction and is processed by 
55 an ICFER instruction. The CFBDKR is a 52 byte record. 

A Crypto Facility Backup DEA Key Record has the following form: 
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Data 



Record ID 

The most eignificant bit in a byte is the leftmost bit. 
0000 0001 - 'Crypto Facility Backup DEA Key Record 1 
Record Code 

PROTOCOL-MODE specified in ECFER (implying ICFER must 
also specify the same) 
xxxx OOxx - invalid 

xxxx Olxx - certification center protocol where the PUA 
control vector has HIST-CHAIN=2 

xxxx lOxx - certification center protocol where the PUA 
control vector has HIST-CHAIN=3 

xxxx llxx - private protocol. 

KMP MODE specified in ECFER (implying ICFER must also 
specify the same) 

xxxx xxOx - KMP-mode = 0 has been specified in ECFER 
xxxx xxlx - KMP-mode = 1 has been specified in ECFER 
KM MODE specified in ECFER (implying ICFER must also 
specify the same) 

xxxx xxxO - KM-mode = 0 has been specified in ECFER 
xxxx xxxl - KM-mode = 1 has been specified in ECFER 
Hash Rule 

Indicates the hash algorithm used to generate the 
hash. 

X'00 f : MDC-2 algorithm with 128-bit hash 
X'01': MDC-4 algorithm with 128-bit hash 

X'02': MD4 algorithm with 128-bit hash 
X'03* - X'FF* : reserved. 
Reserved (=17 X'00«) 

MDC - A 128-bit MDC calculated on a CFER in the CF by 
an ECFER instruction. The MDC is calculated using the 
MDC-2 hash algorithm. 

Key - This field contains a 128-bit odd parity adjusted 
key generated within the CF by the ECFER instruction , 
which may be Exclusive ORed with KM, KMP, or both 
(depending on KMP-mode and KM-mode specified in ECFER). 
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CRYPTO FACILITY SYSTEM SIGNATURE RECORD (CFSSR) 

The Crypto Facility System Signature Record is produced by one of the following instructions: ECFAR, 
EPUK, GKSP, GDS, and ECFER. The CFSSR can be processed by one or more of the following 
5 instructions: IPUK, IDK, VDS, and ICFER. The CFSSR is a 253-bit record. 
A Crypto Facility System Signature Record has the following form: 

Offset Length Data 
10 (in bita) 



75 



25 



30 



Reserved ( =B • 0000 • ) 



4 1 Emulation 

B*l v : CFSSR created via the GDS instruction 
B'O 1 : CFSSR created via the instruction specified 
20 in the first nibble of Record Code field. 

5 8 Record ID (=B'0000 0010' for CFSSR) 



13 16 Record Length (in bits) 

The record length is currently fixed at 
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253 bits (^X'OOFD' ) 

29 8 Record Code 

The first nibble indicates the CF instruction, and 
the second nibble indicates the key type of the 





private 


key used to 


generate the signature 


10 


First nibble: 


Second nibble: 


B'OOOO' 




ECFAR 


B'lOOO' - PRC 




B'OOOl' 




EPUK 


B'1001' - PRM 




B'OOIO' 




GKSP 


B'1010' - PRA 


15 


B'0011 1 




ECFER 


B'lOll 1 - PRU 




B f 0100 




GDS 


B'Oxxx' - reserved 




B'0101 




reserved 


B'llxx' - reserved 


20 


B'Ollx 




reserved 






B' lxxx * 




reserved 





37 8 Hash Rule 

25 Indicates the hash algorithm used to generate the 

hash, and the rule (if any) for formatting and 
producing, from the generated hash value, the value 

30 to be stored in the Hash field* 

X'OO': MDC-2 algorithm with 128-bit hash 
X'Ol': MDC-4 algorithm with 128-bit hash 
X f 02»: MD4 algorithm with 128-bit hash 

35 X*03' - X'FF* : reserved- 

45 208 Hash field 

40 The field in which the hash value is stored-right 

justified, and filled with higher order zero bits* 

45 CRYPTO FACILITY ENVIRONMENT RECORD (CFER) 

The Crypto Facility Environment Record (CFER) contains that portion of a CF Environment necessary to 
"clone" a device (i.e., by replicating the CF Environment of one device into another device). 
The Crypto Facility Environment Record has the following form: 

50 
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10 



Offset Length 
(in bytes) 



Data 



00 
64 

64+a 
DATA 



64 Header (H) 

a Secret Part (SP) 

b Nonsecret Part (NSP) 

DESCRIPTION 



75 



HEADER 



The Header (H) contains information necessary 
to parse the CFER. H has a fixed length of 
64 bytes. 



20 



25 



30 



SECRET PART The Secret Part (SP) contains the secret 

part of the CF Environment to be ported. SP 
is variable length, but a multiple of 8 
bytes . 

NONSECRET PART The Nonsecret Part (NSP) contains ONLY THAT 
PART OF THE NON- SECRET PART OF THE CF 
ENVIRONMENT to be ported. NSP is variable 
length, but contains a whole number of 
bytes. 



35 



The Header has the following form: 



40 



Offset Length Data 
(in bytes) 



00 
00 



64 
01 



Header 

Record ID (=B f 00000011 f ) 
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01 03 Reserved (=3 X'00') 

04 04 Length of Secret Part in 8-byte blocks; (112+a+b)/8 

Value is coded in binary representation- 

5 

08 04 Length of Secret Part of Product Environment in 

bytes ( M a ,f )» Value is coded in binary representation. 

12 03 Reserved (=3 X'OO') 

70 15 oi Length of Random Pad for Secret Part in bytes ("b"). 

Value is coded in binary representation. 

16 04 Length of Nonsecret Part in bytes; (568+d+e). 

Value is coded in binary representation. 

15 

20 02 Reserved (=2 X'00') 

22 02 reserved (=2 X'OO') 

24 04 Length of Nonsecret Part of Product Environment in 

20 bytes ("e"). Value is coded in binary representation. 

28 36 Reserved (=36 X'OO') 

64 00 End of Header 

25 

The Secret Part has the following form: 

64 112+c Secret Part 

30 64 112 Registers 

64 16 CKM Register (Current DEA-key-encrypting Master key) 

80 16 OKM Register (Old DEA-key-encrypting Master key) 

96 8 PRNGCTR1 Register (Pseudo-Random Number Counter #1) 

35 x04 8 PRNGCTR2 Register (Pseudo-Random Number Counter #2) 

112 16 PRNGKEY1 Register (Pseudo-Random Number Seed Key #1) 

128 16 PRNGKEY2 Register (Pseudo-Ransom Number Seed Key #2) 

40 144 16 CKMP Register (Current PKA-key-encrypting Master key) 

160 16 OKMP Register (Old PKA-key-encrypting Master key) 

176 0 End of Registers 

176 a Secret Part of Product Environment 

The product environment contains information specific 
to a product implementation (beyond that called for by 
the PKCD). 

50 176+a b Random Pad 

The Random Pad field contains "b" randomly generated 
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pad bytes, where "b M is a number from 0 to 7. The 
random pad field is adjusted so that the length of the 
Secret Part is guaranteed to be a multiple of 8 bytes. 
176+c 0 End of Secret Part {where c = a+b) 



The Nonsecret Part has the following form: 



10 



15 



20 



25 



30 



35 



•* The next line 
40 664+c d 
664+c+d e 



45 



176+c 488+f Nonsecret Part 
176+c 64 Configuration Vector 

240+c 64 State Vector 

The following flags are reset to reflect that the 

corresponding registers do not port: 

KP FLAG := B * 0 ' 

NKM FLAG := B ' 00 1 

PIN FLAG := B'O' 

KMP FLAG ( 2 ) := B'00' 
304+c 80 Registers 

304+c 16 PROGMDC0 Register (Secure Loadable Program MDC #0) 

320+c 16 PROGMDC1 Register (Secure Loadable Program MDC #1) 

336+c 16 BID Register (Environment Identifier) 

352+c 16 PUACV Register (Public Device Authentication key CV) 

368+c 16 PRACV Register (Private Device Authentication key CV) 

384+c 0 End of Registers 

384+c 272 MDC Table 

656+c 3 Counter Table 

659+c 5 Reserved (=X» 0000000000 • ) 

Keeps remaining fields on an 8 byte boundary, 
is changed from PIN Tables to reserved 
reserved 

Nonsecret Part of Product Environment 
The product environment contains information specific to 
a product implementation (beyond that called for by the 
PKCD). 

664+c+f 0 End of Nonsecret Part (where f = d+e) 

664+c+f 0 End of CFER 



50 
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Outside the CF, the Secret Portion of the CFER is encrypted with a 128 bit DEA key KK1. KK1 is 
generated within the CF and encrypted with a public device authentication key PUA. The Nonsecret Portion 
of the CFER is specifically not encrypted to prevent a covert privacy channel from being set up when the 
CFER is used with the ECFER and ICFER instructions. 
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EXTERNAL CRYPTO FACILITY ENVIRONMENT RECORD (XCFER) 

The External Crypto Facility Environment Record (XCFER) is the same as the CFER expect that the 
Secret Part is encrypted. 
5 The External Crypto Facility Environment Record has the following form: 



Offset 


Length 


Data 


(in bytes) 


00 


64 


Header (H) 


64 


a 


Encrypted Secret Part (ESP) 


64 + a 


b 


Nonsecret Part (NSP) 



75 

DATA DESCRIPTION 

20 HEADER The Header (H) contains information necessary to 
parse the CFER. H has a fixed length of 64 
bytes . 

25 

ENCRYPTED SECRET PART The Encrypted Secret Part (ESP) 

contains the secret part of the CF Environment to 
be ported encrypted under a key shared with, or 
30 to-be-shared with/ a designated receiving device. 

The length of ESP equals the length of SP. SP is 
variable length, but a multiple of 8 bytes. 

35 

NONSECRET PART The Nonsecret Part (NSP) contains the 

nonsecret part of the CF Environment to be 

40 

ported, NSP is variable length, but a whole 
number of bytes. 

45 

CRYPTO FACILITY AUDIT RECORD (CFAR) 

The Crypto Facility Audit Record (CFAR) contains the nonsecret part of the CF Environment plus 
additional nonsecret information. The CFAR is designed to be a multiple of 8 bytes, 
so The Crypto Facility Audit Record has the following form: 



Offset 


Length 


Data 


(in bytes) 




00 


64 


Header (H) 


64 


a 


Nonsecret Part (NSP) 
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DATA DESCRIPTION 

HEADER The Header (H) contains information necessary to 
parse the CFAR. It also contains a random number 
(RN) field and a date and time (DT) field. The 
Header is 64 bytes in length. 

NONSECRET PART The Nonsecret Part (NSP) contains the 

nonsecret part of the CF Environment. NSP is 
variable length , but must be a whole number of 
bytes. The NSP in the CFAR is not the same as 
the NSP in the CFER (see Crypto Facility Environ- 
ment Record) . 

The Header has the following form: 
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Offset Length Data 
(in bytes) 

00 64 Header 

00 01 Record ID (=B' 00000100 ■ ) 

01 03 Reserved (=3 X»00') 

04 04 Length of Nonsecret Part of CF Environment in bytes; 

(520+a+b+d). Value is coded in binary representation 
08 02 Reserved (=2 X'OO 1 ) 

10 02 Length of cfpkrl containing PUA ("a") in bytes. 

Value is coded in binary representation 
12 02 Reserved (=2 X'00') 

• * Next line is changed from PIN-t able- length to reserved 
14 02 reserved (=2 X'OO') 

16 04 Length of Nonsecret Part of Product Environment ("d") 

in bytes. Value is coded in binary representation. 
20 04 Reserved (=4 X'OO') 

24 08 RN field 

32 03 Reserved (=3 X'OO') 

35 14 DT field 

49 15 Reserved (=15 X'OO') 

64 00 End of Header 

DATA DESCRIPTION 

RN An 8 byte CFAP-supplied time-variant parameter. 

This field is set by the ECFAR instruction only 
when process-mode=l or process -mode=2 • This 
field is intended to be used as a nonce in a 
request/response protocol to guarantee freshness 
of the Audit record. The Certification Center 
generates and random number and sends it to the 
device to be audited in the Request-f or-Audit 
message. The device then supplies this random 
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/5 



number to the Export Cryptographic Facility Audit 
Record instruction. This results in the signed 
Audit record being sent to the Certification 

5 

Center by the Audited device with the correct 
nonce. The Certification Center is assured that 
the Audit record is current. 
w DT A 14 character field with format YYYYMMDDHHMMSS 

containing the date and Coordinated Universal 
Time (UTC) . The characters are decimal (0 thru 
9) and are encoded using 8-bit ASCII representa- 
tion. A value of 14 'O's denotes that DT is 
uninitialized. 

20 The Noneecret Part has the following form: 
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64 


520+e 


Nonsecret Part of CF Environment 


64 


64 


Configuration Vector 


128 


64 


State Vector 


192 


112 


Registers 


192 


16 


PROGMDC0 Register 


208 


16 


PROGMDC1 Register 


224 


16 


POS Register 


240 


16 


DID Register 


256 


16 


EID Register 


272 


16 


PUACV Register 


288 


16 


PRACV Register 


304 


0 


End of Registers 


304 


272 


MDC Table 


576 


3 


Counter Table 


579 


5 


Reserved (=5 X'00' ) 

Keeps remaining fields on an 8 byte boundary. 


584 


a 


cfpkxl from the PUA Buffer 


.* Next 


line is changed from PIN Tables to reserved* 


584+a 


b 


reserved 


584+c 


0 


GKSP Save (not audited) 


584+c 


0 


GKSP Buffer Length (not audited) 
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70 



75 



20 



584+c 
584+c 
584+c 
584+c 
584+c 
584+c 
584+c 
584+c 
584+c 



0 
0 
0 
0 
0 
0 
0 
0 
d 



GKSP Record Length 
GKSP Buffer Flag 
GKSP Ticket 
IDK Save 

IDK Buffer Length 
IDK Record Length 
IDK Buffer Flag 
IDK Ticket 



584+e 
584+e 



0 
0 



(not audited) 
(not audited) 
(not audited) 
(not audited) 
(not audited) 
(not audited) 
(not audited) 
(not audited) 

Nonsecret Part of Product Environment (where c = a+b) 
The product environment contains information specific to 
a product implementation (beyond that called for by the 
PKCD) • 

End of Nonsecret Part of CF Environment (where e = c+d) 
End Of CFAR 



No encrypted information in the CFER ever appears in the clear in the CFAR. Specifically, this is done 
25 to prevent a covert privacy channel from being set up when the CFER is used with the ECFER and ICFER 
instructions. 

INTERNAL KEY UNIT (IKU) 

30 The IKU is an internal form of a Key Unit. The Key Unit contains an encrypted CFPKR, an encrypted 
CFKAR, and information about the public or private key in the CFPKR. The IKU is designed to be a multiple 
of 8 bytes. 

The Internal Key Unit has the following form: 



offset 


Length 


Data 


(in bytes) 


00 


32 


Header (H) 


32 


a 


System Control Block (SCB) 


32 + a 


b 


User Control Block (UCB) 


32 + c 


d 


Encrypted Crypto Facility PKA Key Record (ECFPKR), c = a + b 


32 + e 


f 


Encrypted Crypto Facility Key Authenticator Record, e = c + d (ECFKAR) 
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55 
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DATA 



DESCRIPTION 



HEADER The Header (H) contains information necessary to 
parse the IKU. 



contains information about the key in CFPKR, 
including a control vector CI. The SCB is 
managed by the system. The SCB is designed to be 
a multiple of 8 bytes. 



contains information about the key in CFPKR. The 
UCB is specified by the user (or installation). 
The UCB must be a multiple of 8 bytes. 



ENCRYPTED CRYPTO FACILITY PKA KEY RECORD 

The Encrypted Crypto Facility PKA Key Record 



(ECFPKR) contains a CFPKR encrypted under a key 
KMP.C2 formed as the Exclusive OR product of KMP 
and a control vector C2 . C2 is generated from 
SCB and UCB using the method discussed in steps 
501 and 502 of the Key Record Encrypt Algorithm 
12 in Fig. 16. The CFPKR contains a public or 
private key. 



ENCRYPTED CRYPTO FACILITY KEY AUTHENTIC ATOR RECORD 

The Encrypted Crypto Facility Key Authenticator 
Record (ECFKAR) contains a CFKAR encrypted under 
a key KMP.C3 formed as the Exclusive OR product 
of KMP and a control vector C3. C3 is generated 

from SCB and UCB using the method described in 
steps 501 and 502 of the Key Record Encrypt 
Algorithm 12 in Fig. 16- 

The Header has the following form: 



SYSTEM CONTROL BLOCK 



The System Control Block (SCB) 



USER CONTROL BLOCK 



The User Control Block (UCB) 
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Offset Length Data 
(in bytes) 

00 32 Header (H) 

00 02 Anti-ISO field (=X'8080') 

The anti-ISO field is a 2-byte field purposely encoded 
to be invalid as the leading 2 bytes of a data record 
conforming to 'Basic Encoding Rules of ASN.l(ISO 8825)' 

02 01 Record ID (=B* 00000101 • ) 

03 03 (=3 X'OO') 

06 02 SCB-Length - number of 8 byte blocks in SCB. 

Value is coded in binary representation 

SCB-Length must be > 0 
08 02 (=2 X'OO' ) 

10 02 UCB-Length - number of 8 byte blocks in UCB. 

Value is coded in binary representation 

UCB-Length must be >= 0 
12 02 (=2 X , 00 t ) 

14 02 ECFPKR-Length - number of 8 byte blocks in ECFPKR . 

Value is coded in binary representation 

ECFPKR-Length must be > 0 
16 02 (=2 X'00») 

18 02 ECFKAR- Length - number of 8 byte blocks in ECFKAR. 

Value is coded in binary representation 

ECFKAR-Length must be > 0 
20 12 (=12 X'00 1 ) 

32 0 End of Header (H) 

The System Control Block has the following form: 
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offset 


Length 


Data. 


(in by tea) 




32 


a 


System Control Block (SCB) 


32 


16 


Control Vent* or 


48 


16 


EID — Environment ID 


64 


2 


RpqprvpH | apf to ?pro\ 

IxC OCA. ▼ ^ O C (— 1»W *» C A. W / 


66 


14 


Tst art 


80 


2 


R^s^rvpd /set to zero! 


82 


14 


Texp 


96 


4 


Reserved (set to zero) 


100 


4 


Seq 


104 


64 


LDID - Logical Device Identifier 


168 


64 


LKN - Local Key Name 


232 


64 


UID - User Identifier 


296 


b 


Optional CFAP fields 


296+b 


0 


End of System Control Block (SCB) 



DATA DESCRIPTION 

CONTROL VECTOR A 128 bit control vector associate with the 
public or private key stored in the CFPKR. The 
control vector is a CF enforced field. The 
control vector is a required field in the SCB. 

EID A 16 byte Environment ID of the crypto facility 

where IKU is created. EID is a CF enforced field 
(i.e., the CF verifies that EID equals the value 
stored in the EID register of the CF when a key 
is created and, as appropriate, verifies that EID 
is equal or not equal to the value in the EID 
register when an IKU is processed) . Note that 
EID may exist in multiple physical devices, 
depending on the number of "cloned" CF Environ- 
ments active at any one time. EID is a required 
field in the SCB. 
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TSTART A 14 character field with format YYYYMMDDHHMMSS 
containing the date and Coordinated Universal 
Time (UTC) when the IKU becomes active. The 
characters in Tstart are decimal (0 thru 9) and 
are encoded using 8-bit ASCII representation. 
Tstart is a CF enforced field (i.e., the IKU 
10 cannot be processed unless Tstart has passed) . A 

value of 14 ASCII ' O's denotes that Tstart is 
ignored. Tstart is a required field in the SCB. 

75 

TEXP A 14 character field with format YYYYMMDDHHMMSS 

containing the date and Coordinated Universal 
Time (UTC) when the IKU expires. The characters 
20 in Texp are decimal (0 thru 9) and are encoded 

using 8-bit ASCII representation. Texp is a CF 
enforced field (i.e., the IKU cannot be processed 
when Texp has passed). A value of 14 ASCII ' 9's 
denotes that Texp is ignored. Texp is a required 
field in the SCB. 

30 SEQ A 4 byte sequence number. Seq is not a CF 

enforced field. The seq field may be used by CFAP 
to record the relative sequence of IKU in a chain 
starting with a "root" IKU. Seq is an optional 

35 field in the SCB. 

LDID Logical Device Identifier (LDID) is the identifier 

40 of the logical, as opposed to physical, device to 

which IKU belongs. LDID is not a CF enforced 
field. LDID consists of 1 or more name elements 
x L separated by periods (i.e., xl, x2, x3 is 
45 stored as xl.x2.x3). Each name element x j[ is 1 

to 8 characters and is encoded in 8-bit ASCII 
representation. (Note that LDID is the network 
50 equivalent of EID.) LDID is an optional field in 

the SCB. 
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LKN Local Key Name (LKN) is the name or local name of 

the key in IKU and is assigned by the "logical" 
device to which IKU belongs. LKN is not a CF 
enforced field. LKN consists of 1 or more name 
elements x^^ separated by periods (i.e., xl, x2, 
x3 is stored as xl.x2.x3). Each name element 
x^ is 1 to 8 characters and is encoded in 8-bit 
ASCII representation. LDID.LKN and U ID. LKN 
constitute global key names that uniquely identify 
a key. LKN is an optional field in the SCB. 

UID User Identifier (UID) is the identifier of the 

user to which IKU belongs. UID is not a CF 
enforced field. UID consists of 1 or more name 
elements x i separated by periods (i.e., xl, x2, 
x3 is stored as xl.x2.x3). Each name element 
Xj^ is 1 to 8 characters and is encoded in 8-bit 
ASCII representation. UID is an optional field 
in the SCB. 



CLEAR KEY UNIT (CKU) 

The CKU is a clear form of an Internal Key Unit. The Key Unit contains a clear CFPKR and a clear 
CFKAR. The CKU is designed to be a multiple of 8 bytes. 
The Clear Key Unit has the following form: 



Offset 


Length 


Data 


(in bytes) 


00 


32 


Header (H) 


32 


a 


System control Block (SCB) 


32 + a 


b 


User Control Block (UCB) 


32 + c 


d 


Crypto Facility PKA Key Record (CFPKR), c = a + b 


32 + e 


f ! 


Crypto Facility Key Authenticated Record (CFKAR), e = c + d 
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DATA DESCRIPTION 

HEADER The Header (H) contains information necessary to 
parse the CKU. See below. 

SYSTEM CONTROL BLOCK 

The System Control Block (SCB) contains informa- 
tion about the key in CFPKR, including a control 
vector CI. The SCB is managed by the system. 
The SCB is designed to be a multiple of 8 bytes. 
(The SCB form in the CKU is the same as in the 
IKU. ) 

USER CONTROL BLOCK 

The User Control Block (UCB) contains information 
about the key in CFPKR. The UCB is specified by 
the user (or installation). The UCB must be a 
multiple of 8 bytes. (The UCB form in the CKU is 
the same as in the IKU. ) 

CRYPTO FACILITY PKA KEY RECORD 

The Crypto Facility PKA Key Record (CFPKR) 
contains a public or private key. 

CRYPTO FACILITY KEY AUTHENT I C ATOR RECORD 

The Crypto Facility Key Authenticator Record 
(CFKAR) is used by the CF to validate the CFPKR. 

The Header has the following form: 

Offset Length Data 
(in bytes) 



00 32 Header (H) 

00 02 Anti-ISO field (=X'a080 t ) 
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70 



75 



The anti-ISO field is a 2 -byte field purposely encoded 
to be invalid as the leading 2 bytes of a data record 
conforming to 'Basic Encoding Rules of ASN.l(XSO 8825)'. 

02 01 Record ID (=B , 00000110 f ) 

03 03 Reserved (=3 X'OO') 

06 02 SCB-Length - number of 8 byte blocks in SCB. 

Value is coded in binary represent at ion - 
SCB-Length must be > 0 
08 02 Reserved (=2 X'00') 

10 02 UCB-Length - number of 8 byte blocks in UCB. 

Value is coded in binary representation. 
UCB-Length must be >« 0 
12 02 Reserved (=2 X'00') 

20 14 02 CFPKR-Length - number of 8 byte blocks in CFPKR. 

Value 1b coded in binary representation 
CFPKR-Length must be > 0 
16 02 reserved (=2 X'OO') 

25 

18 02 CFKAR-Length - number of 8 byte blocks in CFKAR. 

Value is coded in binary representation. 

CFKAR-Length must be > 0 
30 20 12 Reserved (=12 X'OO') 

32 0 End of Header (H) 



NOTE: The specification for System Control Block, User 
Control Block , Crypto Facility PKA Key Record, and Crypto 
Facility Key Authenticator Record are the same as those for 
the IKU. 

40 

EXTERNAL KEY UNIT (EKU) 

The EKU is an external form of a Key Unit. The Key Unit contains a clear CFPKR and information about 
45 the public or private key in the CFPKR. The EKU has no encrypted or clear CFKAR. The EKU is designed 
to be a multiple of 8 bytes. 

The External Key Unit has the following form: 



Offset 


Length 


Data 


(in bytes) 


00 


32 


Header (H) 


32 


a 


System Control Block (SCB) 


32 + a 


b 


User Control Block (UCB) 


32 + c 


d 


Crypto Facility PKA Key Record (CFPKR), c = a + b 
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DATA DESCRIPTION 

HEADER The Header (H) contains information necessary to 
parse the EKU. 

SYSTEM CONTROL BLOCK 

The System Control Block (SCB) contains in- 
formation about the key in CFPKR, including a 
control vector CI. The SCB is managed by the 
system. The SCB is designed to be a multiple of 
8 bytes. (The SCB form in the EKU is the same as 
in the IKU.) 

USER CONTROL BLOCK 

The User Control Block (UCB) contains information 
about the key in CFPKR. The UCB is specified by 
the user (or installation). The UCB must be a 
multiple of 8 bytes. (The UCB form in the EKU is 
the same as in the IKU. ) 

CRYPTO FACILITY PKA KEY RECORD 

The Crypto Facility PKA Key Record (CFPKR) 
contains a public or private key, although 
ordinarily only public keys occur in an EKU. 

The Header has the following form: 
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Offset Length Data 
(in bytee) 



75 



20 



30 



00 32 Header (H) 

00 02 Anti-ISO field (=X'8080») 

The anti-ISO field iB a 2 -byte field purposely encoded 
io to be invalid as the leading 2 bytes of a data record 

conforming to 'Basic Encoding Rules of ASN.l(ISO 8825)* 

02 01 Record ID (=8*00000111 1 ) 

03 03 Reserved (=3 X'00') 

06 02 SCB-Length - number of 8 byte blocks in SCB. 

Value is coded in binary representation* 
SCB-Length must be > 0 
08 02 Reserved (=2 X'00') 

10 02 UCB- Length - number of 8 byte blocks in UCB. 

Value is coded in binary representation. 
UCB-Length must be >= 0 
25 12 02 Reserved (=2 X'00') 

14 02 CFPKR-Length - number of 8 byte blocks in CFPKR. 

Value is coded in binary representation. 
CFPKR- Length must be > 0 
16 02 reserved (=2 X'OO') 

18 02 Constant (=2 X'00') 

20 12 (=12 X'00' ) 

35 32 0 End of Header (H) 

NOTE: The specification for System Control Block, User 
Control Block, and Crypto Facility PKA Key Record Record 
are the same as those for the IKU. 



40 



SKELETON KEY UNIT (SKU) 

45 

The SKU is a partially completed Key Unit. The SKU is designed to be a multiple of 8 bytes. 
The Skeleton Key Unit has the following form: 



Offset 


Length 


Data 


(in bytes) 


00 


32 


Header (H) 


32 


a 


System Control Block (SCB) 


32 + a 


b 


User Control Block (UCB) 
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DATA 



DESCRIPTION 



HEADER 



The Header (H) contains information necessary to 
parse the SKU. 



SYSTEM CONTROL BLOCK 



The System Control Block (SCB) contains informa- 
tion about the key in CFPKR, including a control 
vector CI, The SCB is managed by the system. 
The SCB is designed to be a multiple of 8 bytes. 
The SCB format is the same as that for the IKU. 



The User Control Block (UCB) contains information 
about the key in CFPKR. The UCB is specified by 
the user (or installation). The UCB is an 
optional field in the SKU. The UCB must be a 
multiple of 8 bytes. 



USER CONTROL BLOCK 



The Header has the following form: 



Offset Length Data 



(in bytes) 



00 



32 



Header (H) 



00 



02 



02 



04 



(=X'8080' ) 
(=4 X'00') 
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70 



75 



20 



25 



30 



06 02 SCB-Length - number of 8 byte blocks in SCB. 

Value is coded in binary representation. 

SCB-Length must be > 0 
08 02 (=2 X'OO') 

10 02 UCB-Length - number of 8 byte blocks in UCB. 

Value is coded in binary representation. 

UCB-Length must be >= 0 
12 02 (=2 X'00 f ) 

14 02 Constant (=2 X'00') 

16 02 (=2 X'00') 

18 02 Constant (=2 X'00') 

20 12 (=12 X'OO*) 

32 0 End of Header (H) 

NOTE: The specification for System Control Block and User 
Control Block are the same as those for the IKU. 

CONTROL VECTOR FORMATS AND DESCRIPTIONS 
AN OVERVIEW OF PKCD KEY TYPES 



Fig. 30 illustrates the PKCD control vector hierarchy. Each PKCD control vector has a CV TYPE field 
consisting of a main-type and a sub-type. The main-type portion of the CV TYPE field permits broad 
classes of keys and cryptovariables to be defined, whereas the sub-type portion of the CV TYPE field 
permits generic key types to be defined within each class, which are more closely associated with the 
35 functional use of the key or cryptovariable. The lefthand portion of Fig. 30 illustrates the control vector main- 
types defined by PKCD. The righthand portion of Fig. 30 illustrates the control vector sub-types defined for 
each main-type. When no sub-type distinction is made, the key or cryptovariable is generally referred to by 
its main-type. 

The PKCD names ascribed to keys are determined by a concatenation of the names associated with 
40 main-type and sub-type. The following keys are defined by PKCD: 

o Public Authentication Key 

o Public Certification Key 

o Public Key Management Key 

o Public User Key 
45 o Private Authentication Key 

o Private Certification Key 

o Private Key Management Key 

o Private User Key 

50 GENERAL FORMAT FOR PKA CONTROL VECTORS 

The fields defined for one or more control vectors are these: 



55 
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II 

ALGORITHM I I GKSP 

ALGORITHM EXTENSION | | HIST-CHAIN 
ANTIVARIANT ONE 
ANT I VARIANT ZERO 
CV TYPE 
DOMAIN ID 
ECPAR 
ECFER 
EPUK 



| | HIST-DOMAIN ID 
| | HIST-IPRK 
| | HIST-IPUK 
| | HIST-KREGMODE 
| | HIST-MDC 
| | ICFER 
II IDK 



I 

| LENGTH 

| PARITY 

| PR USAGE 

| PU USAGE 

| RTNKMP/ RTCKMP 

| SOFTWARE 

| TEST ZERO 

| THRES-MDC 

| VAL/VAL AUTHENT I CATOR 



20 



25 



| EXTENSION | | INSTALLATION | | 

| GADS | | IPUK | | 

| GDS | | KREGMODE | | 

I II M 



*- 



30 



35 



A definition of the control vector fields is provided below in alphabetical order: 
ALGORITHM <4 BITS) 

This field contains an algorithm unique code word which permits the CF to distinguish keys associated 
with one PKA from another. (The architecture permits the CF to implement multiple PKAs.) Each different 
PKA is assigned a different code word. The ALGORITHM field is checked before a key is used by the PKA, 
thus preventing keys associated with one PKA to be used with another PKA. The coding of this field is as 
follows: 

o B'0000' : RSA Algorithm (modulus size from 512 to 2048 bits) 
o B'0001 '-B' 1 1 1 1 ' : reserved 

40 

ALGORITHM EXTENSION <3 BITS) 

This field is an extension of the ALGORITHM field, and the coding is dependent on the value of the 
ALGORITHM field. 

45 For ALGORITHM field = B*0000\ the coding of the ALGORITHM EXTENSION field is as follows: 
o B'000' : No restrictions 
o B'OOT : Public key exponent is 3 
o B'010 f : Public key exponent is 2*M6 + 1 
o B'OIV-B'nr : reserved 

50 

ANTIVARIANT ONE <1 BIT) 

This field is a fixed value of B'1\ 
55 ANTIVARIANT ZERO <1 BIT) 

This field is a fixed value of B'0\ 
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CV TYPE <7 BITS) 

This field indicates the type of the control vector, which is also the key type of the key with which this 
control vector is associated. The following key types are defined for PKA keys : 
5 1. B'1 11 0010': Public Authentication Key 

2. B'1 11 1010': Private Authentication Key 

3. B'1110000': Public Certification Key 

4. B'1 111000': Private Certification Key 

5. BM1 10001': Public Key Management Key 
70 6. B'1111001': Private Key Management Key 

7. B'1110011': Public User Key 

8. B'1111011': Private User Key 

Note that the value of the first three bits of the CV TYPE field of PKA control vectors are always B'1 1 1 \ 
as opposed to other values for DEA control vectors. 

75 

DOMAIN ID <4 BITS) 

This field contains a domain identifier (an arbitrary value from B'0000' to B'111V assigned by an 
installation). The domain ID field of all public and private keys used within a cryptographic instruction must 
20 be equal. 

EC FAR <1 BIT) 

This field indicates whether a private key PR can be used in an ECFAR instruction to generate a digital 
25 signature on a CFAR: 
o B'0' : cannot 
o BT : can 

ECFER <1 BIT) 

30 

In a PRA control vector, this field indicates whether a PRA key can be used in the ECFER instruction to 
generate a digital signature on an XCFER. In a PUA control vector, this field indicates whether a PUA key 
can be used to encrypt a CFBDKB. 
o B'0' : cannot 
35 o B'V : can 

EPUK <1 BIT) 

This field indicates whether a private key can be used in an EPUK instruction to generate a digital 
40 signature on an output External Key Unit (EKU). 
o B'0' : cannot 
o B'1' : can 

EXTENSION <2 BITS) 

This field indicates whether the control vector is a 64-bit, 128-bit, or >128-bit control vector. In PKCD , 
ail control vectors are > 128-bit control vectors, 
o B'00' : 64 bit control vector base 
o B*01' : the control vector is a 128-bit control vector 
50 o B'10 f : the control vector is a >128-brt control vector 
o B'1V : reserved 

GADS <1 BIT) 

55 This field indicates whether a private key (PRC, PRM or PRU) can be used in a GADS instruction to 
generate a digital signature, 
o B'0' : cannot 
o B'1' : can 
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6DS <1 BIT) 

This field indicates whether a private key (PRA, PRC, PRM or PRU) can be used in a 6DS instruction to 
generate a digital signature. 
5 o B' 0' : cannot 
o BT : can 

GKSP<1 BIT) 

w This field indicates whether a key (PRM or PUM) can be used in a GKSP instruction, 
o B'O' : cannot 
o BT : can 

HIST-CHAIN <2 BITS) 

75 

This field indicates a chain of history of how a public key has been imported in the IPUK instruction: 
o B'00' : other (i.e., not B'OT, B*10\ or B'11 f ) 
o B'OT : conditions stated in (a) or (b) must be true: 

- (a) PU in EKU1 is a PUC and is imported via import-mode = 0; 

20 - (b) PU in EKU1 is a PUC and is imported via import-mode = 1 ; PU in IKU2 is a PUC with HIST- 

IPUK^ and HIST-CHAIN = 1; PU in EKU1 and PU in IKU2 have same DOMAIN ID. 
o B'10* : conditions stated in (c) or (d) must be true: 

- (c) PU in EKU1 is a PUM and is imported via import-mode = 1 ; PU in IKU2 is a PUC with HIST- 
IPUK^ and HIST-CHAIN = 1; PU in EKU1 and PU in IKU1 have same DOMAIN ID. 

25 - (d) PU in EKU1 is a PUA and is imported via import-mode = 1 ; PU in IKU2 is a PUC with HIST- 

IPUK = 1 and HIST-CHAIN = 1. 
o B'1 1 ' : conditions stated in (e) must be true: 

- (e) : PU in EKU1 is a PUA with HIST-IPUK = 0 and is imported via import-mode = 1; PU in IKU2 is a 
PUM with HIST-IPUK = 1 and HIST-CHAIN « 2. 

30 NOTE: this field is valid only when HIST-IPUK = BT. 

HIST-DOMAIN ID <4 BITS) 

HIST-DOMAIN ID is a field in a PUA control vector used to record the value of DOMAIN ID in a PUC or 
35 PUM control vector. A domain identifier is an arbitrary value from B'0000' to B'1 111'. PUA is a key in an 
EKU imported with IPUK and PUM or PUC is a key used to validate the digital signature previously 
generated on the to-be-imported EKU at the sending device. 

NOTE: this field is valid only when HIST-IPUK = BT and either HIST-CHAIN = B'10' or HIST-CHAIN 
= B'11\ 

40 

HIST-IPRK <1 BITS) 

This field indicates whether a private user key has been imported via the IPRK instruction, as follows: 
o B'O' : not imported via IPRK 
45 o BT : imported via IPRK 

HIST-IPUK <1 BITS) 

This field indicates whether a public key (PUA, PUC. PUM, or PUU) has been imported via the IPUK 
50 instruction, as follows: 

o B'0' : not imported via IPUK 
o BT : imported via IPUK 
NOTE: the HIST-MDC and HIST-CHAIN fields in the control vector are valid only when HIST-IPUK in 
the control vector = BT. HIST-KREGMODE is valid only when HIST-IPUK = B'1 ' and HIST-CHAIN = B'1 V 

55 
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H1ST-KREGMODE <2 BITS) 

HIST-KREGMODE is a field in a PUA control vector used to record the value of KREGMODE in a PUM 
control vector. See also KREGMODE. PUA is a key in an EKU imported with IPUK and PUM is a key used 
5 to validate the digital signature previously generated on the to-be-imported EKU at the sending device. 
0 BW : KREGMODE = BW in PUM 
o B'OT : KREGMODE = B'OT in PUM 
o B'10' : KREGMODE = B'10' in PUM 
o B'1 V : reserved 

to NOTE: this field is valid only when HIST-IPUK = BT and HIST-CHAIN = B'11\ 
HIST-MDC <2 BITS) 

This field records IPUK information about a root PU in a chain, as follows: 
75 o B'OO' : reserved 

o B'OT : root PU was imported in IPUK using MDC-mode = 0 (i.e., no MDC) 

o B*10' : root PU was imported in IPUK using MDC-mode = 1 (i.e. with MDC) such that EKUMDC 
FLAG = B'1 0\ 

o BMV : root PU was imported in IPUK using MDC-mode = 1 (i.e., with MDC) such that EKUMDC 
20 FLAG = BMV. 

NOTE: this field is valid only when HIST-IPUK = BT. 

ICFER <1 BIT) 

25 In a PUA control vector, this field indicates whether a PUA key can be used in the ICFER instruction to 
validate a digital signature on an XCFER. In a PRA control vector, this field indicates whether a PRA key 
can be used to decrypt an encrypted CFBDKB. 

o B'O' : cannot 

o BT :can 



30 



50 



IDK <1 BIT) 



This field indicates whether a key (PRM or PUM) can be used in an IDK instruction, 
o B f 0' : cannot 
35 o BM' : can 

INSTALLATION <7 BITS) 

This field represents control vector bits that are controlled/managed entirely by the installation. The 
40 INSTALLATION field is not checked/enforced by the hardware (CF). 

IPUK <1 BIT) 

This field indicates whether a public key can be used in an IPUK instruction to validate a digital 
45 signature on an input External Key Unit (EKU). 
o B'Q' : cannot 
o B f V : can 

NOTE: the IPUK usage bit does not control the use of PU in an EKU to validate a signature on that same 
EKU. 



KREGMODE <2 BITS) 



This field indicates the method used to register a public key management key (PUM) in a certification 
center environment. 
55 o BW : PUM not registered 

o B'OT : PUM registered without restrictions 
o B'10' : PUM registered with restrictions 
o BMV : reserved 
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LENGTH <16 BITS) 

This field contains a length value which directly or indirectly determines key length or key size. The 
coding and interpretation of the LENGTH field is dependent of the ALGORITHM field. 
5 For ALGORITHM = B'OOOO* (i.e., RSA) the LENGTH field contains a value from 512 to 2048 
representing modulus length in bits. Unless elsewhere restricted, the public and private keys can range in 
length up to the modulus length. The key generator shall ensure that if LENGTH = n, then a modulus is 
generated such that the value of the modulus is BT followed by n-1 zero and one bits. 

10 PARITY <1 6 BITS) 

This is a set of bits in the control vector reserved for use by CFAP and by the the algorithm used to 
calculate the Hash Function h. The PARITY bits are used to set even byte parity on the 128-bit value H = h- 
(C) produced by applying Hash Function h to control vector C. 

PR USAGE <7 BITS) 

In a PR control vector, PR USAGE consists of architected usage bits and reserved bits. The PR USAGE 
field is also stored as history information in the associated PU control vector. 
The following PR USAGE subfields are defined for a PRA control vector: 
o ECFAR <1 bit) 
o EPUK <1 bit) 
o ECFER <1 bit) 
o ICFER <1 bit) 
o GDS <1 bit) 

The following PR USAGE subfields are defined for a PRC control vector: 
o ECFAR <1 bit) 

o RTNPMK/RTCPMK <1 bit), reserved ( = BT) 
o EPUK <1 bit) 
o GDS <1 bit) 
o GADS <1 bit) 

The following PR USAGE subfields are defined for a PRM control vector: 
o ECFAR (1 bit) 

o RTNPMK/RTCPMK <1 bit), reserved ( = B'V) 
o EPUK<1 bit) 
o GDS <1 bit) 
o GKSP <1 bit) 
o IDK<1 bit) 
o GADS <1 bit) 

The following PR USAGE subfields are defined for a PRU control vector: 
o ECFAR <1 bit) 

o RTNPMK/RTCPMK <1 bit), reserved ( = B'1 ') 
o EPUK<1 bit) 
o GDS <1 bit) 
o GADS <1 bit) 

PU USAGE <7 BITS) 

In a PU control vector, PU USAGE consists of architected usage bits and reserved bits. The PU USAGE 
50 field is also stored as history information in the associated PR control vector. 
The following PU USAGE subfields are defined for a PUA control vector: 
o RTNPMK/RTCPMK <1 bit), reserved ( = BT) 
o IPUK <1 bit) 
o ECFER <1 bit) 
55 o ICFER <1 bit) 

The following PU USAGE subfields are defined for a PUC control vector: 
o RTNPMK/RTCPMK <1 bit), reserved ( = BT) 
o IPUK <1 bit) 
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The following PU USAGE subfields are defined for a PUM control vector: 
o RTNPMK/RTCPMK <1 bit), reserved ( = BT) 
o IPUK <1 bit) 
o GKSP <1 bit) 
5 o IDK <1 bit) 

The following PU USAGE subfields are defined for a PUU control vector: 
o RTNPMK/RTCPMK <1 bit), reserved ( = BT) 
o IPUK <1 bit) 

w RTNKMP/RTCKMP <1 BIT) 

This field indicates whether a public or private key can be reenciphered in an RTNKMP or RTCKMP 
instruction: 

o B f 0' : cannot 
75 o BT : can 

NOTE: This field has a fixed value of BT, and is enforced in the GDAK and GPUPR instruction. 
SOFTWARE <6 BITS) 

20 This field represents control vector bits that are controlled/managed entirely by CFAP. The SOFTWARE 
field is not checked/enforced by the hardware (CF). 

TESTZERO <3 BITS) 

25 This field is reserved by the CF and tested for zero. That is, TESTZERO must equal B'000'. 
THRES-MDC <2 BITS) 

This field is used in a PRMa control vector to establish a threshold on HIST-MDC in a corresponding 
30 PUMb control vector. The PRMa and PUMb are used together in a GKSP or IDK instruction. Note that "a rt 
represents this device and "b" another device, 
o BW : reserved 

o B'OT : HIST-MDC must be > = B'OT 
o B'10' : HIST-MDC must be > = B'10' 
35 o B'11': HIST-MDC must be = B'1V 

VALUE/AUTHENTICATOR <1 BIT) 

The VALUE/AUTHENTICATOR field is reserved for use by the algorithm used to calculate the Hash 
40 Function h. 

The layout of control vectors for all PKCD keys are described in Figs. 31 through 38, inclusive. 
GENERAL FORMAT FOR THE HASH VECTOR 
45 A definition of the hash vector fields is provided below in alphabetical order: 
ANTIVARIANT ONE <1 BIT) 

This field is a fixed value of BT. 

50 

ANTIVARIANT ZERO <1 BIT) 

This field is a fixed value of B'O*. 

55 EXTENSION <2 BITS) 

This field indicates whether the hash vector is produced from a 64-bit, 128-bit, or > 128-bit control 
vector. In PKCD , all hash vectors are produced from > 128-bit control vectors. 
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o BW : hash vector produced from 64 bit control vector 
o B'0V : hash vector produced from 128-bit control vector 
o B'10' : hash vector produced from > 128-bit control vector 
o B'11' : reserved 

5 

HASH <107 BITS) 

The HASH field Consists of 107 bits of a 128 bit Modification Detection Code (MDC) produced by using 
the MDC-2 hash algorithm. The HASH field consists of bits 00. .06, 08. .14, 16. .22, 24. .29, 32^ .37 40. .44, 
w 48. .54, 56. .61, 64. .70, 72. .78, 80. .86, 88. .94, 96. .102, 104. .110, 112. .118, 120. .126 from the MDC. 

PARITY (16 BITS) 

The PARITY bits are used to set even byte parity on the 128 hash vector. 

75 

VALUE/AUTHENTICATOR <1 BIT) 

The VALUE/AUTHENTICATOR field indicates whether the hash vector is associated with a value or an 
authenticator, as follows: 
20 o B'O* : value 

o BT : authenticator 
The layout of the Hash vector is described in Fig. 39. 



25 



INSTRUCTION PROCESSING 
INSTRUCTION SET 

The CF instructions may be logically divided into eight functional categories: 

30 CF INITIALIZATION 

These instructions support various CF initialization, including the PKA master key. 
CF CONFIGURATION 

35 

This instruction is used to load a configuration vector into the CF. 
CF AUDIT 

40 This instruction is used to export the nonsecret portion of the CF environment. 
CF CONTROL 

These instructions are used to control instruction execution and to change CF state. 
CKDS UPDATE 

These instructions are used to reencipher the keys in a CKDS from a current to a new, or an old to a 
current, PKA master key. 



45 



50 



55 



KEY MANAGEMENT 

These instructions are used to generate, export, and import PKCD PKA keys. They are also used to 
generate and import DEA key-encrypting keys. 

SYSTEM DIGITAL SIGNATURES 

These instructions are used to generate and verify system digital signatures. 
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APPLICATION DIGITAL SIGNATURES 

These instructions are used to generate and verify application digital signatures. 
5 CRYPTO FACILITY BACKUP 

These instructions are used to export and import a CF environment. 
UTILITY 



w 



These instructions provide miscellaneous cryptographic functions. 
The instructions are listed by group in the following table: 



75 



| Table 1 (Page 1 of 3). 



| INSTRUCTION NAME 



20 +- 



| INSTRUCTION MNEMONIC 



CF INITIALIZATION: 



25 

| Load Physical Identifier 
| Generate Device Authentication Key Pair 
| Load First PKA Master Key Part 
30 | combine PKA Master Key Parts 

+ 



| LPID 
| GDAK 
| LFPMKP 
| CPMKP 
-+ 



35 



40 



45 



50 



55 
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5 



70 



30 



35 



40 



45 







+ 


| Table 1 (Page 2 of 3). 


+ 


1 

+ 


+ 






| INSTRUCTION NAME 


| INSTRUCTION 


MNEMONIC | 




+ 


+ 


+ 












| Generate New PKA Master Key 


| GNPMK 


1 


| Generate New DEA Master Key 


| GNDMK 


1 


| Set PKA Master Key 


| SPMK 


1 


| Load MDC For Public Certification Key 


| LMDCC 


1 


| Load MDC 


| LMDC 


i 


| Initialize Pseudo Random Number Generator 


| IPRNG 
+ 


1 

+ 












1 




+ 


+ 


1 T naH Pnnf imirflt Lon Vector 


| LCV 

+ 


1 

+ 








| CF AUDIT: 


+ 


1 

+ 


+ - 






| Export Crypto Facility Audit Record 


| ECFAR 
+ 


1 

+ 


+ 






| CF CONTROL: 




1 




+ 


_ + 


+ " 

1 F.nt-or Preinit State 


| EPS 


1 


| Enter I nit State 


| EIS 


1 


| Enter Run State 


| ERS 


1 


| Clear New PKA Master Key Register 


| CLNPMK 


1 


| Clear Old PKA Master Key Register 


| CLOPMK 


1 


| Set Authorization Flag 


| SAF 


1 


| Set Enable Flag 


| SEF 


1 




+ 




+ - ~ — 






| CKDS UPDATE: 




1 




+ 




| Reencipher to New PKA Master Key 


| RTNPMK 


1 


| Reencipher to Current PKA Master Key 


| RTCPMK 

+ 


1 

+ 
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Table 1 (Page 3 of 3). 



INSTRUCTION NAME 



INSTRUCTION MNEMONIC 



10 



75 



20 



25 



30 



35 



40 



45 



50 



55 



KEY MANAGEMENT: 



Generate Public and Private Key Pair 

Export Public Key 

Import Public Key 

Import Private Key 

Generate Key Set PKA 

Import DBA Key 

Verify Internal Key Unit 



SYSTEM DIGITAL SIGNATURES: 



GF 
EPUK 
IPUK 
IPRK 
GKSP 
IDK 
VIKU 



| Generate Digital Signature 
| Verify Digital Signature 

+ 

| APPLICATION DIGITAL SIGNATURES: 
+ 



GDS 
VDS 



Generate Application Digital Signature 
Verify Application Digital Signature 



+ 

| CRYPTO FACILITY BACKUP: 
+ 



GADS 
VADS 



Export Crypto Facility Environment Record 
Import Crypto Facility Environment Record 



+ 

| UTILITY: 

+ 

| Set and Reset Alarm 
+ 



ECFER 
ICFER 



| SRALM 



CF INITIALIZATION 

Load Physical Device ID (LPID) 
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EQUATION: 



PID /128b/ 
— > 

CC /unspecified/ 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

PID A 128 bit physical identifier of a device. 

OUTPUTS DESCRIPTION 

cc Condition code indicating success or failure 

of the instruction execution. 

DESCRIPTION: 

The Load Physical Device ID instruction permits a 128 bit physical identifier of a device to be loaded 
into the CF and stored in the DID and EID registers. Execution of the LPID instruction causes the DID flag to 
be set to the "full" state. The instruction executes only when the DID flag is in the "empty" state. (Note that 
an EPS instruction must be executed in order to reset the DID flag to the "empty" state.) The DID flag 
serves two purposes: (a) it controls the execution of the LPID instruction, and (b) it indicates whether the 
DID and EID registers have or have not been initialized. 

The value of PID stored in the DID register is the PID value associated with PUA and PRA (i.e., the PUA 
and PRA of that device). 

The value of PID stored in the EID register is used for two purposes: (a) it is the value stored in the 
EIDO field of a certificate, and thus identifies the device to another device, and (b) it is the value stored in a 
DEA key record, which is used by the GKSP and IDK instructions as an antireimport value. 

The 16 byte PID consists of an 8 byte network part and an 8 byte node part. The 8 byte node part 
uniquely identifies the node within a network. The 8 byte network part uniquely identifies the network. The 
objective is to arrive at a naming convention that will ensure unique PID values from one network to another. 
One possibility is for the 8 byte network part to be registered (e.g., with an IBM registration center). 

The ECFAR instruction can be used by CFAP to read the contents of the DID and EID registers. 

For reasons of security, the LPID instruction is architected such that the DID register contents cannot be 
changed without erasing the contents of the PUA and PRA buffers (i.e., a different PID can't be assigned to 
the same key pair stored in the PUA and PRA buffers). In like manner, the ICFER instruction is architected 
such that the EID register contents cannot be changed without reinitializing the CKMP register with a new 
key. Otherwise, use of the EID buffer as an anti-reimport value would be ineffective. 

The LPID instruction executes only in the "preinit" state. 
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Generate Device Authentication Key Pair (GDAK) 

EQUATION: 

5 CI /128 bits/ 

C2 /128 bits/ 

— > 

10 CC /unspecified/ 



75 



20 



25 



30 



35 



PARAMETER DEFINITIONS: 



INPUTS DESCRIPTION 



CI A 128 bit control vector associated with the 

generated public authentication key PUA. 

C2 A 128 bit control vector associated with the 

generated private authentication key PRA. 

OUTPUTS DESCRIPTION 

CC Condition code indicating success or failure 

of the instruction execution. 



DESCRIPTION: 

The Generate Device Authentication Key Pair instruction generates a public and private authentication 
40 key pair, PUA and PRA. The generated keys are stored in the PUA buffer and PRA buffer in the CF, 
respectively, as Crypto Facility PKA Key Record 1 (CFPKR1) and Crypto Facility PKA Key Record 2 
(CFPKR2). The 128 bit control vectors associated with PUA and PRA are specified to the GDAK instruction 
as inputs C1 and C2, respectively. The control vectors specify the public key algorithm and other algorithm 
related information necessary for key generation. Consistency checking is performed on C1 and C2. For 
45 example, the ALGORITHM, ALGORITHM EXTENSION, and LENGTH fields in C1 and C2 must match. 

Execution of the GDAK instruction causes the GDAK FLAG in the state vector to be set to the "full" 
state from the "empty" state. The instruction executes only when the GDAK FLAG is in the "empty" state. 
(Note that the EPS instruction must be executed to reset the GDAK FLAG to the "empty" state.) 

The GDAK FLAG serves two purposes: (a) it controls execution of the GDAK instruction, and (b) it 
so indicates when the PUA and PRA buffers have been initialized. 
The GDAK instruction executes only in the "preinit" state. 

FUNCTIONAL SPECIFICATION: 

55 1. Perform input parameter consistency checking: None. 
2. Perform state vector checking: 

a. Verify that CF STATE in the state vector is in the "preinit" state. 

b. Verify that GDAK FLAG in state vector is in the "empty" state. 
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Continue if checking succeeds; otherwise set CC status flag and jump to step 8. 

3. Perform control vector checking. Continue if checking succeeds; otherwise set CC status flag and 
jump to step 8. 

4. Store control vectors: 

a. Store C1 in PUACV Register 

b. Store C2 in PRACV Register 

5. Generate a pair of cryptographic facility PKA records cfpkrl and cfpkr2 of length s1 and s2, 
respectively, where si and s2 are pre-selected values that indicate the number of 8 byte blocks. 

6. Store generated keys and lengths: 

a. Store s1 in PUA Buffer Length field in CF Environment. 

b. Store cfpkrl in PUA Buffer in CF Environment. 

c. Store s2 in PRA Buffer Length field in CF Environment. 

d. Store cfpkr2 in PRA Buffer in CF Environment. 

7. Perform state vector update. 

a. Set GDAK FLAG to the "full" state. 

8. Produce output CC from CC status flags. 

CONTROL BLOCK AND CONTROL VECTOR CHECKING: 

Perform control vector checking: 

1 . Checking on C1 (associated with PUA) 

a. Verify CV TYPE = 'public authentication key 1 

b. Note: checking on CV TYPE EXTENSION has been deleted. 

c. Verify RTNKMP/RTCKMP usage bit = BT 

d. Perform Control Vector Validate on C1 to validate certain fields in C1. 

e. Verify RC1=0. 

If any of the above checking fails then stop the control vector checking and issue a condition code to 
indicate that C1 is not valid. 

2. Checking on C2 (associated with PRA): 

a. Verify CV TYPE = 'private authentication key' 

b. Perform Control Vector Validate on C1 to validate certain fields in CI. 

c. Verify RC1 =0. 

If any of the above checking fails then stop the control vector checking and issue a condition code to 
indicate that C2 is not valid. 

3. Checking on C1 and C2: 

a. Note: checking on CV TYPE EXTENSION has been deleted. 

b. Verify ALGORITHM in C1 = ALGORITHM in C2 

c. Verify ALGORITHM EXTENSION in C1 = ALGORITHM EXTENSION in C2 

d. Verify LENGTH in C1 = LENGTH in C2 

e. Verify PR USAGE in C1 = PR USAGE in C2 

f. Verify PU USAGE in C1 = PU USAGE in C2 

If any of the above checking fails then stop the control vector checking and issue a condition code to 
indicate that cross checking among control vectors has failed. 

Note that there is no cross checking on (1) DOMAIN ID since this field is not implemented in the 
PUA and PRA control vectors. 
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Load First PKA Master Key Port (LFPMKP) 

EQUATION: 

input-mode /lb minimum/ 

<key-part> /128b/ ; if input-mode=0 

— > 

CC /unspecified/ 

PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

INPUT-MODE specifies how the key part to be processed 

is supplied to the instruction. 

o 0 : the key part is passed via the 

instruction interface , i.e., via input 
parameter key-part. 

o 1 : the key part is retrieved from the 
internal KP register. 

KEY-PART 128 bit key part. This parameter is 

required only when input-mode=0 . 

OUTPUTS DESCRIPTION 

CC Condition code indicating success or failure 

of the instruction execution. 

DESCRIPTION: 

The Load First PKA Master Key Part instruction loads the first part of the PKA master key (KMP) into 
the NKMP (New PKA Master Key) register. An input-mode parameter indicates whether the loaded key part 
is passed as an input parameter at the instruction interface or whether it is retrieved from the internal KP 
register. The NKMP flag is set to the "partially full" state from the "empty" state and the NKMP History 
Flag is set to 0 (indicating that the contents of the NKMP register were loaded via the LFPMKP instruction). 
If input-mode = 1, the operation is performed only if the KP flag is in the "full" state; in which case the KP 
flag is set to the "empty" state. The operation is performed only if the NKMP flag is in the "empty" state. 
NOTE: If input-mode = 1 , it is assumed that prior to the execution of this instruction the first PKA master key 
part has been entered into the key part register via a key-entry device, keyboard, etc., which, optionally, 
may operate only in a special authorized mode (e.g., supersecure mode enabled via a physical key- 
activated switch). 
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The LFPMKP instruction executes only in the "run" state. 
Combine PKA Master Key Parts (CPMKP) 



5 EQUATION: 

input-mode 
mode 

<key-part> 
— > 
CC 



10 



/lb minimum/ 
/lb minimum/ 
/128b/ 

/unspecified/ 



; if input-mode-0 



75 



20 



25 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

INPUT-MODE specifies how the key part to be processed 
is supplied to the instruction. 

o 0 : the key part is passed via the 

instruction interface , i.e., via input 



30 



35 



40 



45 



50 



55 
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parameter key-part. 

o 1 : the key part is retrieved from the 
internal KP register. 



MODE 



10 



indicates whether the PKA master key part in 
the key part register is an intermediate key 
part or a last key part. 



75 



intermediate key part 



1 : last key part 



20 



KEY- PART 



128 bit key part. This parameter is required 
only when input-mode=0 . 



25 



30 



OUTPUTS 



CC 



DESCRIPTION 

Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

35 The Combine PKA Master Key Parts instruction Exclusive ORs a PKA master key part with the PKA 
master key part stored in the NKMP register and stores the result in the NKMP register. An input-mode 
parameter indicates whether the loaded key part is passed as an input parameter at the instruction interface 
or whether it is retrieved from the internal KP register. The NKMP flag is set to the "full" state if mode = 1 
or to the "partially full" state if mode = 0. For mode = 1, the CPMKP instruction ensures that the produced 

40 value of KMP has odd parity (odd parity adjusted, if necessary) and that the left and right 64 bit parts of 
KMP are not equal. If input-mode = 1 , the operation is performed only if the KP flag is in the "full" state; in 
which case the KP flag is set to the "empty" state. The operation is performed only if the NKMP flag is in 
the "partially full" state and the NKMP History flag is zero. The instruction has no output. 
NOTE: If input-mode = 1, it is assumed that prior to the execution of this instruction a PKA master key part 

45 has been entered into the key part register via a key-entry device, keyboard, etc., which, optionally, may 
operate only in a special authorized mode (e.g., supersecure mode enabled via a physical key-activated 
switch). 

The CPMKP instruction executes only in the "run" state, 
so Generate New PKA Master Key (GNPMK) 
EQUATION: 

() 

55 —> 

CC /unspecified/ 
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PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

None. 

OUTPUTS DESCRIPTION 

cc Condition code indicating success or failure 

of the instruction execution. 

DESCRIPTION: 

The Generate New PKA Master Key instruction causes a 128 bit odd parity adjusted random number to 
be generated and stored in the NKMP register. The left and right 64 bit parts of the generated key must be 
unequal. The instruction executes only if the NKMP flag is in the "empty" state. Successful execution Of 
the GNPMK instruction causes the NKMP flag to be set to the "full" state from the "empty state and the 
NKMP History flag to be set : = BT. 

The GNPMK instruction executes only in the "run" state. 

25 Generate New DEA Master Key (GNDMK) 

EQUATION: 

() 

— > 

30 

Cc /unspecified/ 



70 



15 



20 



35 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 



40 None . 

OUTPUTS DESCRIPTION 



45 



50 



55 



cc Condition code indicating success or failure 

of the instruction execution. 



DESCRIPTION: 



The Generate New DEA Master Key instruction causes a 128 bit odd parity adjusted random number to 
be generated and stored in the new master key register (i.e., the NKM register). The left and right 64 bit 
parts of the generated key must be unequal. The instruction executes only if the NKM flag is in the empty 
state. Successful execution of the GNDMK instruction causes the NMK flag to be set to the "full" state from 
the "empty 55 state. 



74 



EP 0 534 419 A2 



The GNDMK instruction executes only in the "run" state. 
Set PKA Master Key (SPMK) 
5 EQUATION: 



w 



15 



25 



50 



55 



() 

CC /unspecified/ 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 



None. 



20 OUTPUTS DESCRIPTION 



CC Condition code indicating success or failure 

of the instruction execution. 



DESCRIPTION: 

30 The Set PKA Master Key instruction transfers the contents of the CKMP register into the OKMP register 
and then transfers the contents of the NKMP register into the CKMP register. This instruction operates only 
if the NKMP flag (new PKA master key flag) is in the "full" state and the left and right 64 bit parts of the key 
stored in the NKMP register are unequal. Also, if the CKMP flag is in the "full" state and CKMP HISTORY 
= 1, then the instruction operates only if NKMP HISTORY = 1. This guarantees that a CF-generated KMP 
35 can't be replaced by a CFAP-supplied KMP. 

The SPMK instruction is used to activate a new KMP after the RTNPMK instruction has been used to 
reencipher encrypted records in the CKDS from encryption under the current KMP to a new KMP. 
The SPMK instruction executes only in the "run" state. 

40 Load MDC For Public Certification Key (LMDCC) 

EQUATION: 

index-value /4b/ 
45 MDC-value /128b/ 

— > 

CC /unspecified/ 



PARAMETER DEFINITIONS: 
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INPUTS 
INDEX-VALUE 

MDC -VALUE 



DESCRIPTION 

A 5 bit field containing an index value from 
0 to 15. 

A 128 bit modification detection code to be 
loaded into one of 16 128-bit storage 
locations in MDC Table , designated as 
EKUMDC(O), EKUMDC(15). 



OUTPUTS 



DESCRIPTION 



CC 



Condition code indicating success or failure 



of the instruction execution. 



DESCRIPTION: 

The Load MDC For Public Certification Key instruction permits a 128 bit MDC, designated MDC-value, 
to be loaded and stored in the CF in one of 16 possible storage locations in MDC Table, designated as 
EKUMDC(O) EKUMDC(15). MDC-value is stored in EKUMDC(i), where i is the value of index- value. 
MDC-value contains an MDC calculated on an External Key Unit (EKU) using one of several possible 
hashing algorithms (see the hash-rule parameter of the IPUK instruction). The EKU must contain a public 
certification key PUC. (The fact that EKU contains a public certification key is verified when EKU is imported 
using the IPUK instruction.) The Load MDC For Public Certification Key instruction sets EKUMDC FLAG(i) 

The LMDCC instruction operates only when EKUMDC FLAG(i) = B'00\ Other- wise, to load an MDC 
into an already occupied MDC Table location requires EKUMDC FLAG(i) to be reset to B'00\ This can be 
done only be issuing an EPS or EIS instruction. For reasons of security, the LMDCC instruction is 
architected such that the MDC Table locations EKUMDC(O) thru EKUMDC(15) cannot be changed without 
erasing the contents of the CKMP register. Thus, a certification center has the means to audit each security 
module to ensure that public certification keys have been loaded in conformance with an established 
network security policy. 

The EKUMDC FLAG serves the following purposes: (a) it controls initialization of the MDC Table via the 
LMDCC and LMDC instructions, and (b) it controls import of public keys via the "MDC-mode" parameter of 
the IPUK instruction. 

The ECFAR instruction can be used by CFAP to view the contents of the MDC Table and the EKUMDC 
FLAG field. 

The LMDCC instruction executes only in the "run** state. 
Load MDC (LMDC) 
EQUATION: 

MDC-value /128b/ 
--> 

CC /unspecified/ 
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70 



75 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

MDC- VALUE A 128 bit modification detection code to be 

loaded into EKUMDC(16). 

OUTPUTS DESCRIPTION 

CC Condition code indicating success or 

failure of the instruction execution. 

DESCRIPTION: 

20 The Load MDC instruction permits a 128 bit MDC to be loaded and stored in MDC Table storage 
location EKUMDC(16). MDC-value contains an MDC calculated on an External Key Unit (EKU) using one of 
several possible hashing algorithms (see the hash-rule parameter of the IPUK instruction). The EKU must 
contain a public key management key, a public authentication key, or a public user key (no public 
certification key). (The fact that EKU contains a public key management key, a public authentication key, or 

25 a public user key is verified when EKU is imported using the IPUK instruction.) 

Unlike the LMDCC instruction, the LMDC instruction executes regardless of the current value of 
EKUMDC FLAG(1 6). Execution of the LMDC instruction causes MDC-value to be loaded into EKUMDC(16) 
and EKUMDC FLAG(16) to be set equal to B'10\ 

The EKUMDC FLAG serves the following purposes: (a) it controls initialization of the MDC Table via the 

30 LMDCC and LMDC instructions, and (b) it controls import of public keys via the "MDC-mode" parameter of 
the IPUK instruction. 

The ECFAR instruction can be used by CFAP to view the contents of the MDC Table and the EKUMDC 
FLAG field. 

The LMDC instruction executes only in the "run" state. 



35 



40 



Initialize Pseudorandom Number Generator (IPRNG) 

EQUATION: 



() 
— > 

CC /unspecified/ 



45 

PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

50 

None. 

OUTPUTS DESCRIPTION 

55 
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70 



75 



cc Condition code indicating success or failure 

of the instruction execution. 



DESCRIPTION: 

The Initialize Pseudorandom Number Generator Instruction initializes the pseudorandom number gener- 
ator using the method specified in the Initialize PseudoRandom Number algorithm (Initialize Pseudo- 
random Number). The Initialize Pseudo-random Number algorithm reads the current values stored in the 
PRNGKEY1 , PRNGKEY2, and PRNGCTR1 registers and calculates two new key values which are then 
stored back into the PRNGKEY1 and PRNGKEY2 registers. 

The IPRNG instruction executes in the "preinit", "init", and "run" states. 



CF CONFIGURATION 

Load Configuration Vector (LCV) 
20 EQUATION: 



conf ig-vector /5 12b/ 



--> 



CC /unspecified/ 



25 



PARAMETER DEFINITIONS: 
30 INPUTS DESCRIPTION 



CONF IG-VECTOR A configuration vector. 
OUTPUTS DESCRIPTION 



35 



40 



cc condition code indicating success or failure 

of the instruction execution. 



45 DESCRIPTION: 

The Load Configuration Vector instruction permits a 64 byte configuration vector to be loaded and 
stored within the CF Environment. Execution of the LCV instruction causes the LCV FLAG to be set to the 
-full" state. The LCV instruction executes only when the LCV FLAG is in the empty state. The LCV FLAG 
can only be reset to the "empty" state via execution of an EPS or EIS instruction. In effect, the LCV FLAG 
controls LCV execution as follows: (a) If the LCV FLAG = "empty" state, then LCV instruction execution is 
enabled for one execution only, whereas (b) if the LCV FLAG = "full" state, then LCV instruction execution 

' S d, Secution of the EIS instruction causes a configuration vector in the CF Environment to be 
initialized/reinitialized to a "default" value. This value can be changed by executing an LCV instruction. 

For reasons of security, the LCV instruction is architected such that the configuration vector vaue 
stored in the CF Environment cannot be changed without erasing or invalidating the contents of the CKMP 
buffer. 



50 



55 
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The LCV instruction executes only in the "init" state. 
FUNCTIONAL SPECIFICATION: 

1. Perform configuration vector and state vector checking: 

a. Verify that CF STATE in the state vector is in the "init" state. 

b. Verify that LCV FLAG in the state vector is in the empty" state. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 5. 

2. Perform consistency checking on config-vector: 

a. Verify Version Number = X'OT 

b. Verify KM RELOAD = B'0\ 

c. Verify DEFINE(EPS) = B'V or DEFINE(EIS) = B'V (i.e., either EPS or EIS or both are defined to 
prevent CF-reinitialization lockout) 

d. For i = 0 to 71, do the following: 1) Verify DEFINE(i) = B'V. 2) Verify AUTH CONTROL(i) = B'O*. 

e. For i = 72 to start-inst-index minus 1 , do the following: 

1) Verify DEFINE(i) = B'O'. 

2) Verify AUTH CONTROL(i) = B'O'. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 5. 

3. Load the value of config-vector into the configuration vector. 

4. Perform state vector update: 

a. Set LCV FLAG to the "full" state. 

b. For i = start-inst-index to 143. process AUTH CONTROL as follows: 

1) If AUTH CONTROL(i) = B'0\ then set AUTH(i) : = B'0' and ENABLE(i) : = B'OO' 

2) If AUTH CONTROL(i) = BT, then set AUTH(i) : = B w r and ENABLE(i) := B'11' 

5. Produce output CC from CC status flags. 

CONTROL VECTOR CHECKING: 
None. 

Export Crypto Facility Audit Record (ECFAR) 



EQUATION: 

process-mode 

PUA-key 

product-component 

<hash-rule> 

<IKUl-length> 

<IKU1> 

<RN> 

— > 

c far- length 
cfar 

<dsigl-length> 

<dsigl> 

CC 



/2b minimum/ 
/lb minimum/ 
/lb minimum/ 
/3b minimum/ 
/16b/ 

/unspecified/ 
/64b/ 

/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/unspecified/ 



; if process-mode = (1 or 2) 

; if process-mode = 2 

; if process-mode = 2 

; if process-mode = (1 or 2) 



; if process-mode » (1 or 2) 
; if process-mode «= (1 or 2) 



PARAMETER DEFINITIONS: 
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DESCRIPTION 

The process -mode parameter specifies the 
type of processing to be performed: 

o process-mode = 0 : no digital signature 

is generated 
o process -mode = 1 : a digital signature 
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is generated on CFAR1 using the private 

authentication key PRA stored in the PRA 

buffer in the CF. 
o process-mode = 2 : a digital signature 

is generated on CFAR1 using the private 

key PR specified in IKU1. 
o process-mode = 3 : reserved 



PUA-KEY The PUA-key parameter indicates whether the 

cfar should contain cfpkrl, which contains 
the PUA key: 

o PUA- key =0 : no 
o PUA-key=l : yes 



PRODUCT -COMPONENT 

The product-component parameter indicates 
whether the cfar should contain the Nonsecret 
Product Environment: 



o product-component=0 : no 
o product-component=l : yes 



HASH-RULE Specifies the hash algorithm to be used to 

calculate a hash value on cfar* The encoding 
of the hash-rule is as follows: 



o hash-rule = 0 : MDC-2 algorithm 

o hash-rule = 1 : MDC-4 algorithm 

o hash-rule = 2 : MD4 algorithm 

o hash-rule = 3 : quadratic residue 

o hash-rule = 4-7 : reserved 



This parameter is required only when 
process -mode=l or process -mode=2 . 
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I KU 1 -LENGTH 



IKU1 



The length of IKU1 in bytes. This parameter 
is required only when process -raode=2 . 

An Internal Key Unit containing a private 
key PR. This parameter is required only 
when process -mode=2 . The value of EID in 
SCB1 must equal the value in the EID register. 
The values of Tstart and Texp in SCB1 must 
satisfy the relationship Tstart < DT < Texp, 
where DT is the current date and time 
expressed in Coordinated Universal Time. 



RN 



A CFAP-supplied time-variant parameter to be 
stored in CFARl. This parameter is required 
only when process -mode=l or process-mode=2 . 



OUTPUTS 



DESCRIPTION 



C FAR -LENGTH The length of cfar in bytes, 



CFAR 



DSIG1- LENGTH 



DSIG1 



CC 



A Crypto Facility Audit Record. 

The length of dsigl in bits. This parameter 
is required only when process-mode=l or 
process-mode=2 . 

A digital signature produced from a CF 
System Signature Record (CFSSR) and a 
private key PR, in accordance with section 6 
of ISO DIS 9796. The CFSSR contains a 
128-bit hash value calculated on cfar. This 
parameter is required only when process-mode=l 
or process -mode=2 . 

Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Export Crypto Facility Audit Record instruction constructs a Crypto Facility Audit Record (CFAR) 
and returns it to the CFAP. The CFAR contains (1) a copy of the nonsecret part of the CF Environment, a 
date and time (DT) supplied by the CF, and (3) foo process-mode = 1 and process-mode = 2, a CFAP- 
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supplied time-variant value RN. RN can be a random number, sequence number, or time stamp, which may 
be used by a designated receiving device to ensure that a produced CFAR is current. 

A process-mode parameter specifies to the instruction whether a digital signature is generated on the 
CFAR and, if so, then whether the private key is (1) PRA or (2) a PR supplied to the ECFAR instruction. A 
5 hash-rule parameter indicates to the ECFAR instruction the hash algorithm to be used in generating the 
digital signature. 

Process-mode = 1 can only be executed when the GDAK FLAG is in the "full" state. Process-mode = 2 
can only be executed when the CKMP FLAG is in the "full" state. 

The Export Crypto Facility Audit Record instruction executes in the "preinit", "init", and "run" states. 

w 

CF CONTROL 

Enter Preinit State (EPS) 
15 EQUATION: 

() 

— > 

CC /unspecified/ 

20 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

25 

None. 



30 OUTPUTS DESCRIPTION 

CC Condition code indicating success or failure 

of the instruction execution. 

35 

DESCRIPTION: 

40 The Enter Preinit State instruction resets the CF STATE to the "preinit" state; it resets the configuration 
and state vectors to zero; it resets the POS register to value X , 0123456789ABCDEF0123456789ABCDEF; 
and it executes algorithm Initialize Pseudo-random Number to (further) initialize the pseudorandom number 
generator. The Enter Preinit State instruction DOES NOT erase or zeroize the PRNGCTR1 , PRNGCTR2, 
PRNGKEY1, and PRNGKEY2 registers, which are registers used by the Initialize Pseudo-random Number. 

4 5 ......... 

Enter Init State (EIS) 

EQUATION: 

() 

50 

> 

CC /unspecified/ 



55 

PARAMETER DEFINITIONS: 
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INPUTS DESCRIPTION 
None. 

5 

OUTPUTS DESCRIPTION 

10 cc Condition code indicating success or failure 

of the instruction execution. 



DESCRIPTION: 

The Enter Init State instruction loads a "default" configuration vector into the CF environment and 
resets certain flags in the state vector to change the state of the CF and to clear certain registers and 
20 buffers. (See "Configuration Vector" on page 32 for a description of the default configuration vector.) More 
particularly, the Enter Init State instruction causes the flags controlling the old, current, and new KMP 
registers to be reset to the "empty" state, thereby causing these keys to be invalid. It causes EKUMDC 
FLAG field to be reset to zero, thereby invalidating any MDCs currently loaded in the MDC Table. It causes 
the LCV FLAG to be reset to the "empty" state, thereby enabling execution of the LCV instruction. It causes 
25 the CF STATE to be reset to the "init" state. 

The Enter Init State instruction does not reset flags associated with the master key KM. 
The EIS instruction can be executed in the "preinit", "init", and "run" states. 

Enter Run State (ERS) 

30 

EQUATION: 

() 



35 CC /unspecified/ 



40 PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

None. 

45 

OUTPUTS DESCRIPTION 

50 cc Condition code indicating success or failure 

of the instruction execution. 



55 
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DESCRIPTION: 

The Enter Run State instruction causes the CF STATE flag to be set to the "run" state. 
The ERS instruction executes only in the "init" state. 

5 

Clear New PKA Master Key Register (CLNPMK) 

EQUATION: 

() 

70 

> 

CC /unspecified/ 

75 

PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

20 None . 

OUTPUTS DESCRIPTION 

25 

CC Condition code indicating success or failure 

of the instruction execution. 

30 

DESCRIPTION: 

The Clear New PKA Master Key Register instruction causes the NKMP flag in the state vector to be 
35 reset to the "empty" state. 

The Clear New PKA Master Key Register instruction executes only in the "run" state. 

Clear Old PKA Master Key Register (CLOPMK) 

40 EQUATION: 

() 
— > 

CC /unspecified/ 

45 

PARAMETER DEFINITIONS: 

50 
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INPUTS 



DESCRIPTION 



None. 



OUTPUTS 



DESCRIPTION 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Clear Old PKA Master Key Register instruction causes the OKMP flag in the state vector to be 
reset to the "empty" state. 

The Clear Old PKA Master Key Register instruction executes only in the "run" state. 

Set Authorization Fiag (SAF) 

EQUATION: 



inst-index 



/16b/ 



— > 



CC 



/unspecified/ 



PARAMETER DEFINITIONS: 



86 



EPO 534 419 A2 



INPUTS 



DESCRIPTION 



10 



15 



INST- INDEX An instruction and instruction-mode index 

referencing AUTH(inst-index) in the AUTH 
field of the state vector, inst-index is a 
positive integer value between start-inst- 
index and 143, inclusive. See Configuration 
Table for a definition of start-inst-index 
and end inst-index. See also AUTH field in 
the state vector, 

inst-index is value referencing the following 
PKCD instructions and instruction modes: 



20 



25 



110 VADS 

111 SRALM 

112 IPRNG 

113 EPS 

114 ECFAR 

115 EIS 



121 CPMKP (input 0) 132 IPRK (input 0) 

122 CPMKP (input 1) 133 IPRK (input 1) 

123 GNPMK 134 RTNPMK 

124 GNDMK 135 RTCPMK 

125 CLNPMK 136 GKSP 

126 CLOPMK 137 IDK 



30 



35 



116 SAF 

117 LMDCC 

118 LMDC 

119 LFPMKP (input 0) 130 EPUK 

120 LFPMKP (input 1) 131 IPUK 



127 SPMK 138 GADS 

128 GPUPR (mode 0/2) 139 GDS 

129 GPUPR (mode 1) 140 VDS 

141 ECFER 

142 ICFER 

143 VIK0 



40 



OUTPUTS 



DESCRIPTION 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

50 

The Set Authorization Flag instruction permits an AUTH flag asssociated with a particular instruction or 
instruction mode to be set to the "authorization required" state. Initially, the AUTH flag may be in the 
"authorization not required" or "authorization required" state. 

AUTH flags are reset to the "authorization not required" state via execution of an EPS or EIS 
55 instruction. 

The Set Authorization Flag instruction executes in the "init" and "run" states. 
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Set Enable Flag (SEF) 

EQUATION: 

inst-index 

flag-val 

<ctr> 



/16b/ 

/2b minimum/ 
/8b/ 



<r> 
<V> 
— > 
CC 



; if inst-index^'CPMXP input-mode^O 
or inet-index^'CPMKP input-mode=l 
or inst-index='GPUPR mode=0/2 ■ 

/16b/ 

/unspecified/ 



/unspecified/ 



PARAMETER DEFINITIONS: 
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INPUTS 



DESCRIPTION 



70 



75 



20 



INST-INDEX An instruction and instruction-mode index 

referencing ENABLE ( ins t- index) in the ENABLE 
field of the state vector, inst-index is a 
positive integer value between start-inst- 
index and 143, inclusive. See Configuration 
Table for a definition of start-inst-index 
and 143. See also ENABLE field in the state 
vector . 

inst-index is value referencing the PKCD 
instructions and instruction modes, as 
follows : 



25 



30 



35 



110 VADS 

111 SRALM 

112 IPRNG 

113 EPS 

114 ECFAR 

115 EIS 

116 SAF 

117 LMDCC 

118 LMDC 

119 LFPMKP (input 0) 130 EPUK 

120 LFPMKP (input 1) 131 IPUK 



121 CPMKP (input 0) 132 IPRK (input 0) 

122 CPMKP (input 1) 133 IPRK (input 1) 

123 GNPMK 134 RTNPMK 

124 GNDMK 135 RTCPMK 

125 CLNPMK 136 GKSP 

126 CLOPMK 137 IDK 

127 SPMK 138 GADS 

128 GPUPR (mode 0/2) 139 GDS 

129 GPUPR (mode 1) 140 VDS 

141 ECFER 

142 ICFER 

143 VIKU 



40 



FLAG-VAL 



A parameter specifying the ENABLE (inst-index) 



45 



50 



55 
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value/ as follows: 

o 0 : enabled for any number of executions. 

o 1 : enabled for 1 execution only. 

o 2 : enabled for n (n= 1 thru 255) 
executions, where n is specified in 
input parameter ctr. 

o 3 : not enabled 

The permitted values of flag-val for each 
instruction and instruction mode are listed 
below (see also the ENABLE field in the 
state vector for a description of ENABLE ( ins t- 
index) values which are valid and invalid) . 

inat inot 



index 




0 1 


2 3 
* 


index 
*— __— 




0 1 


2 3 
— * 


108 


reserved 


1 1 1 


1 1 


| 127 


SPMK 


lylyl 


lyl 


109 


reserved 


1 1 1 


1 1 


| 128 


GP0PR (mode 0/2) |y| 


y|yl 


110 


VADS 


lYl 


lyl 


| 129 


GPUPR (mode 1) 


lyl t 


lyl 


111 


SRALM 


lyl 


lyl 


| 130 


EPUK 


lyl 


lyl 


112 


IPRNG 


|yl 


lyl 


1 131 


IPUK 


|y| 


lyl 


113 


EPS 


|y| 


lyl 


| 132 


IPRK (input 0) 


lyl 


lyl 


114 


ECFAR 


lYl 


lyl 


| 133 


IPRK (input 1) 


lyl 


1 lyl 


115 


EIS 


lyl 


lyl 


| 134 


RTNPMK 


lyl 


1 lyl 


116 


SAP 


|y| 


lyl 


| 135 


RTCPMK 


lyl 


1 lyl 


117 


LMDCC 


|y|y 


lyl 


| 136 


GKSP 


lyl 


1 lyl 


118 


LMDC 


|y|y 


lyl 


| 137 


IDK 


lyl 


1 lyl 


119 


LFPMKP (input 0) 


|y|y 


lyl 


| 138 


GADS 


lyl 


1 lyl 


120 


LFPMKP (input 1) 


|y|y 


lyl 


| 139 


GDS 


lyl 


1 lyl 


121 


CPMKP (input 0) 


lyl 


y|yl 


| 140 


VDS 


lyl 


1 lyl 


122 


CPMKP (input 1) 


|y| 


lylyl 


| 141 


ECFER 


|y|y 


1 lyl 
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| 123 GNPMK |y|y| |y( 

| 124 GNDMK |y|y| |y| 

| 125 CLNPMK |y| | |y| 

| 126 CLOPMK |y| | |y| 



| 142 ICFER |y| | |y| 

I 143 VIKU |y| | |y| 

I I I I I I 

I I I I I I 



10 



15 



CTR 



A counter specifying a number (1 thru 255) of 
permitted executions of the instruction or 
instruction-mode specified by inst-index. This 
parameter is required only when inst-index^'CPMKP 
input-mode=0 " or inst-index= # CPMKP input-mode=l ■ 
or inst-index= f GPUPR mode=0/2'. 



20 



The length of V in bytes. This parameter is 
required only when V is present. 



25 



30 



A parameter containing proof of authorization. 
The specification of what V contains, the format 
of V, and the processing performed on V is not 
defined by the PKCD. This is an implementation 
choice. This parameter is optional and is needed 
only when required by the implementation. 



35 



OUTPUTS DESCRIPTION 



CC 



Condition code indicating success or failure of 
the instruction execution. 



40 

DESCRIPTION: 

The Set Enable Flag instruction permits an ENABLE flag associated with a particular instruction or 
45 instruction mode to be set to one of its permitted ENABLE flag values. The possible ENABLE flag values 
are (1) enabled, (2) enabled for 1 execution, (3) enabled for n execution, where n is a number from 1 to 255, 
and (4) disabled. 

The ENABLE flag value supported by each instruction vary. See the definition of the flag-val parameter. 
The SEF instruction has no associated DEFINE, AUTH CONTROL, AUTH, and ENABLE flags to control 
50 SEF instruction execution. 

The SEF instruction executes in the "init" and "run" states. 

CKDS UPDATE 

55 Reencipher To New PKA Master Key (RTNPMK) 
EQUATION: 
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IKUl-length 

IKU1 

— > 

IKU2 

CC 



/16b/ 

/unspecified/ 

/unspecified/ 
/unspecified/ 



10 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 



is I KUl -LENGTH The length of IKU1 in bytes, 



20 



IKU1 



OUTPUTS 



An Internal Key Unit, 
DESCRIPTION 



25 



IKU2 



An Internal Key Unit. The length of IKU2 in 
bytes is equal to IKUl-length. 



30 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

35 . 

The Reencipher To New PKA Master Key instruction reenciphers an IKU from encryption under the 
current PKA master key (CKMP) to encryption under a new PKA master key (NKMP). The instruction 
operates only if the CKMP FLAG and the NKMP FLAG are in the "full" states. Also, if CKMP has been 
generated via the GNPMK instruction, then the instruction operates only if NKMP has been generated via 
40 the GNPMK instruction. 

The RTNPMK instruction executes only in the "run" state. 



Reencipher To Current PKA Master Key (RTCPMK) 



45 EQUATION: 

IKUl-length /16b/ 

IKU1 /unspecified/ 

— > 

50 IKU2 /unspecified/ 

CC /unspecified/ 



55 

PARAMETER DEFINITIONS: 
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INPUTS DESCRIPTION 

I KU1 -LENGTH The length of IKU1 in bytes. 
IKU1 An Internal Key Unit. 

DESCRIPTION 

An Internal Key Unit. The length of IKU2 in 
bytes is equal to IKUl-length. 

Condition code indicating success or failure 
of the instruction execution. 



™ OUTPUTS 
IKU2 

75 

cc 



DESCRIPTION: 



25 The Reencipher To Current PKA Master Key instruction reenciphers an IKU from encryption under the 
old PKA master key (OKMP) to encryption under the current PKA master key (CKMP). The instruction 
operates only if the OKMP FLAG and the CKMP FLAG are in the "full" states. 
The RTCPMK instruction executes only in the "run" state. 

30 KEY MANAGEMENT 

Generate Public and Private Key Pair (GPUPR) 



35 



40 



45 



50 



55 



EQUATION: 



gen-mode 
<codeword> 
SKUl-length 
SKU1 

SKU2-length 

SKU2 

— > 

IKUl-length 
IKU1 

<IKU2-length> 
<IKU2> 

<EKU2-length> 

<EKU2> 

CC 



/2b minimum/ 

/128b/ 

/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/unspecified/ 



; if gen-mode=l 



; if gen-mode=0 or gen-mode=l 

; if gen-mode=0 or gen-mode=l 
; if gen-mode =2 
; if gen-roode=2 
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PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

GEN-MODE The gen-mode parameter specifies the generation 

mode of the GPUPR instruction* 

o gen-mode=0 : PU and PR are randomly 

generated. The generated (PU,PR) are a 
(PUC,PRC), (PUM,PRM), or (PUU,PRU). PU 
and PR are output as IKU1 and IKU2, 
respectively. 

o gen-mode=l : PU and PR are generated 
from codeword, such that whenever the 
same codeword is specified to the GPUPR 
instruction the same (PU,PR) pair is 
generated. The generated (PU,PR) is a 
(PUU,PRU). PU and PR are output as 
IKU1 and IKU2, respectively. 

o gen-mode=2 : PU and PR are randomly 
generated. The generated (PU,PR) is a 
(PUU,PRU). PU and PR are output as 
IKU1 and EKU1 / respectively. 

CODEWORD A value using by the key generator to 

derive PU and PR. 

SKU1 -LENGTH The length of SKU1 in bytes. 

SKU1 A Skeleton Key Unit for to-be -generated PU. 

SKU2 -LENGTH The length of SKU2 in bytes. 
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SKU2 

OUTPUTS 

I KU1- LENGTH 

IKU1 



A Skeleton Key Unit for to-be-generated PR. 
DESCRIPTION 

The length of IKUl in bytes. 

An Internal Key Unit containing generated 
PU. The value of EID in SCB1 must equal the 
value in the EID register. The value of 
Texp in SCB1 must satisfy the relationship 
DT < Texp, where DT is the current date and 
time expressed in Coordinated Universal Time. 



I KU2- LENGTH 



The length of IKU2 in bytes. This parameter 
is required only when gen-mode=0 or gen-mode=l. 



IKU2 



EKU2 -LENGTH 



EKU2 



An Internal Key Unit containing generated 
PR. This parameter is required only when 
gen-mode=0 or gen-mode=l. The value of EID 
in SCB2 must equal the value in SCB1. The 
values of Tstart and Texp in SCB2 must equal 
the values of Tstart and Texp in SCB1. 

The length of EKU2 in bytes. This parameter 
is required only when gen-mode=2. 

An External Key Unit containing generated 
PR. This parameter is required only when 
gen-mode=2 . 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Generate Public and Private Key Pair instruction generates a public and private key pair, PU and 
PR, and stores each key in and Internal Key Unit (IKU) or External Key Unit (EKU) depending the value of a 
gen-mode parameter supplied to the Generate Public and Private Key Pair instruction. 

For gen-mode = 0, the generated keys can be a (PUC.PRC), (PUM.PRM), or (PUU.PRU) key pair. 
However, to generate a (PUC.PRC) pair, the device must be configured as a certification center (i.e., 
CERTIFICATION = B'V must be specified in the configuration vector). Both PU and PR are output as 
Internal Key Units. 

For gen-mode = 1, the generated keys can be a (PUU.PRU) key pair only. In this case, the keys are 
generate from a 128 bit code word supplied to the Generate Public and Private Key Pair instruction. Both 
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PUU and PRU are output as Internal Key Units. 

For gen-mode = 2, the generated keys can be a (PUU.PRU) key pair only. PUU is output as an Internal 
Key Unit and PRU is output as an External Key Unit (i.e., PRU is output In clear form). 

The attributes of the to-be-generated keys, PU and PR, are specified in Skeleton Key Units, SKU1, and 
SKU2, respectively. Consistency checking is performed on the control blocks and control vectors in SKU1 
and SKU2, prior to generating PU and PR. Control Vector fields such as ALGORITHM, ALGORITHM 
EXTENSION, LENGTH, DOMAIN ID must be the same for both PU and PR. The EID field in SCB1 of SKU1 
and the EID field in SCB2 of SKU2 must be equal to the value stored in the EID register of the CF (i.e., the 
EID value originally set using an LPID instruction). 

The control vector fields ALGORITHM, ALGORITHM EXTENSION, and LENGTH specify to the 
cryptographic facility the public key algorithm and other key generation information sufficient to permit 
(PU,PR) to be generated. 

The Generate Public and Private Key Pair instruction executes only in the "run" state. 

FUNCTIONAL SPECIFICATION: 

1 . Perform input parameter consistency checking: 

a. Verify gen-mode has value 0,1, or 2 

b. Verify that SKU1 is consistent to definition of an SKU. 

c. Verify that SKU2 is consistent to definition of an SKU. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 9. 

2. Perform configuration vector and state vector checking: 

a. Verify that CF STATE in state vector is in the "run" state. 

b. Verify that KMP-FLAG(CKMP) in state vector is in the "full" state. 

c. If gen-mode = 0 or gen-mode = 2, then do: 

1) Verify that DEFINE(GPUPR mode =0/2) in config. vector = BT. 

2) Verify that ENABLE(GPUPR mode = 0/2) in state vector = B'00' or B'10\ 

d. If gen-mode = 1 then do: 

1) Verify that DEFINE(GPUPR mode = 1) in config. vector = BT. 

2) Verify that ENABLE(GPUPR mode = 1) in state vector = BW. 
Continue if checking succeeds; otherwise set CC status flag and jump to step 9. 

3. Perform control block and control vector checking. Continue if checking succeeds; otherwise set CC 
status flag and jump to step 9. 

4. Generate Keys: 

a. If gen-mode = 0 or gen-mode = 2, then perform PKA Key Generation to generate a pair of public 
and private cryptographic facility PKA records cfpkrl and cfpkr2, respectively. The length of cfpkrl 
and cfpkr2 are s1 and s2, respectively, where s1 and s2 are pre-selected values that indicate the 
number of 8 byte blocks. 

b. If gen-mode = 1, then perform PKA Key Generation, with code-word supplied as an input, to re- 
generate a pair of public and private cryptographic facility PKA records cfpkrl and cfpkr2, respec- 
tively. The length of cfpkrl and cfpkr2 are s1 and s2, respectively, where s1 and s2 are pre-selected 
values that indicate the number of 8 byte blocks. 

5. Prepare outputs IKU1-length and IKU1: 

a. Construct a key authenticator record cfkarl from the key record cfpkrl, using the method specified 
in Key Record Encrypt Algorithm 12. 

b. Construct a clear key unit CKU1 from SKU1, cfpkrl, and cfkarl. 

c. Set CKMP := value of KMP stored in the CKMP register. 

d. Perform Encipher Clear Key Unit on CKU1 to obtain an internal key unit IKU1, using CKMP as the 
master key KMP. 

6. Prepare outputs IKU2-length and IKU2, if gen-mode = 0 or gen-mode = 1: 

a. Construct a key authenticator record cfkar2 from the key record cfpkr2, using the method specified 
in Key Record Encrypt Algorithm 12. 

b. Construct a clear key unit CKU2 from SKU2, cfpkr2, and cfkar2. 

C. Perform Encipher Clear Key Unit on CKU2 to obtain an internal key unit IKU2, using CKMP as the 
master key KMP. 

7. Prepare outputs EKU2-length and EKU2, if gen-mode = 2: a. Construct an external key unit EKU2 from 
SKU2 and cfpkr2. 

8. Perform state vector update: 
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a. If (gen-mode = 0 and ENABLE(GPUPR mode = 0/2) = B'10') or (gen-mode = 2 and ENABLE(GPUPR 
mode = 0/2) = B'10'), then do: 

1) Decrement COUNTER(GPUPR mode = 0/2) in Counter Table by 1. 

2) If COUNTER(GPUPR mode = 0/2) = 0, then reset ENABLE(GPUPR mode = 0/2) := B'1V (i.e., 
5 reset the ENABLE Rag to the "disabled" state). 

9. Produce output CC from CC status flags. 

CONTROL BLOCK AND CONTROL VECTOR CHECKING: 

w Perform control block and control vector checking: 

1. Extract SCB1 and C1 from SKU1: 

a. Extract the system control block SCB1 from SKU1. 

b. Extract control vector C1 from SCB1. 

2. Extract SCB2 and C2 from SKU2: 

75 a. Extract the system control block SCB2 from SKU2. 

b. Extract control vector C2 from SCB2. 

3. Checking on C1 (associated with public key): 

a. If gen-mode = 0, then verify CV TYPE in C1 = 'public certification key* or 'public key management 
key' or 'public user key 1 
20 b. If gen-mode = 1 or gen-mode = 2, then verify CV TYPE in C1 = 'public user key' 

c. Verify RTNPMK/RTCPMK in C1 = BT (i.e., 'enabled') 

d. Verify HIST-IPUK in C1 = B'0' (i.e., 'not imported') 

4. Checking on C2 (associated with private key): 

a. If CV TYPE in C2 = 'PRU', then verify HIST-IPRK in C2 = B'0' (i.e., not imported via IPRK 
25 instruction) 

b. Verify RTNPMK/RTCPMK in C2 = BT (i.e., 'enabled') 

5. Checking on C1 and C2 (i.e., for a PUC/PRC, PUM/PRM, or PUU/PRU): 

a. Verify (CV TYPE in C1) XOR B'0001000' = (CV TYPE in C2) 

b. Verify (ALGORITHM in C1) = (ALGORITHM in C2) 

30 c. Verify (ALGORITHM EXTENSION in C1) = (ALGORITHM EXTENSION in C2) 

d. Verify (LENGTH in C1) = (LENGTH in C2) 

e. Verify (DOMAIN ID in C1) = (DOMAIN ID in C2) 

f. Verify (PR USAGE in C1) = (PR USAGE in C2) 

g. Verify (PU USAGE in C1) = (PU USAGE in C2) 
35 6. Checking on C1 and configuration vector: 

a. If CV TYPE in C1 = 'public certification key', then verify CERTIFICATION in config. vector = BT 
(i.e., certification center). 

b. If (CV TYPE in C1 = 'public key management key') and (KREGMODE in C1 = B'OV), then verify 
KREG in config. vector = B'0'. 

40 7. Checking on C2 and configuration vector, if CV TYPE in C2 = 'private key management key': 
a. Verify THRES-MDC in C2 > = FLOOR-MDC in config. vector. 

8. (optional) Checking on SCB1: 

a. (optional) Verify that the current date and time is less than the expiration time Texp specified in 
SCB1. 

45 b. (optional) Verify that the Environment ID stored in the EID register is the same as the Environment 

ID stored in SCB1 . 
NOTE: : Tstart, Texp, and EID are checked only when an IKU is used. 

9. Checking on SCB1 and SCB2: 

a. Verify that the values of Environment ID stored in SCB1 and SCB2 are the same. 
50 b. Verify that the values of Tstart stored in SCB1 and SCB2 are the same. 

c. Verify that the values of Texp stored in SCB1 and SCB2 are the same. 
Continue if checking succeeds; otherwise set CC status flag and jump to step 9. 

Export Public Key (EPUK) 

55 

EQUATION: 
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PU-mode 

PR-mode 

<hash-rule> 

<IKUl-length> 

<IKU1> 



/lb minimum/ 
/2b minimum/ 
/3b minimum/ 
/16b/ 

/unspecified/ 



; if PR~mode=2 or PR-mode=3 
; if PU~mode=0 
; if PU-mode=0 



<IKU2-length> 

<IKU2> 

C3 

— > 

EK03-length 
EKU3 

<dsigl-length> 

<dsigl> 

CC 



/16b/ 

/unspecified/ 
/128b/ 

/16b/ 

/unspecified/ 
/16b/ 

/un spec i f ied / 
/unspecified/ 



; if PR-mode=2 
; if PR-mode=2 



; if PR-mode=2 or PR-roode=3 
; if PR-mode=2 or PR-mode=*3 



PARAMETER DEFINITIONS: 



98 



EP 0 534 419 A2 



INPUTS 
PU-MODE 



w 



15 



20 



25 



30 



35 



40 



45 



50 



PR-MODE 



HASH-RULE 



DESCRIPTION 

The PU-mode parameter specifies the source 
of the public key to be exported, as follows: 
o PU-mode=0 : use PU in IKU1 
o PU-mode=l : use PUA in CF 

The PR-mode parameter specifies whether a 

digital signature is generated and, if so, 

then also the source of PR. 

o PR-mode=0 : no 

o PR-mode=l : reserved 

o PR-mode=2 : yes, use PR in IKU2 

o PR-mode=3 : yes, use PRA in CF 

Specifies the hash algorithm to be used to 

calculate a hash value on EKU3. The encoding 

of the hash-rule is as follows: 

o hash-rule = 0 : MDC-2 algorithm 

o hash-rule = 1 : MDC-4 algorithm 

o hash-rule = 2 : MD4 algorithm 

o hash-rule = 3 : quadratic residue 

o hash-rule = 4-7 : reserved 



55 
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This parameter is required only when PR-mode=2 
or PR-mode=3. 



IKU1 -LENGTH 



IKU1 



The length of IKU1 in bytes. This parameter 
is required only when PU-mode=0. 

An Internal Key Unit containing PU. This 
parameter is required only when PU-mode=0 No 
checking is performed on the EID, Tstart, 
and Texp fields in SCB1. 



IKU2 -LENGTH 



IKU2 



C3 



The length of IKU2 in bytes. This parameter 
is required only when PR-mode=2 . 

An Internal Key Unit containing PR. This 
parameter is required only when PR-mode=2. 
The value of EID in SCB2 must equal the 
value in the EID register. The values of 
Tstart and Texp in SCB2 must satisfy the 
relationship Tstart < DT < Texp, where DT is 
the current date and time expressed in 
Coordinated Universal Time. 

A 16 byte control vector for to-be-exported PU. 



OUTPUTS 



DESCRIPTION 



EKU3 -LENGTH The length of EKU3 in bytes. 



EKU3 



An External Key Unit containing the exported 
PU. 



DSIG1 -LENGTH The length of dsigl in bits. This parameter 
is required only when PR-mode=2 or PR-mode=3. 



DSIG1 



A digital signature produced from a CF 
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System Signature Record (CFSSR) and a 
private key PR, in accordance with section 6 
of ISO DIS 9796. The CFSSR contains a 
5 128-bit hash value calculated on EKU3 . This 

parameter is required only when PR-mode=2 or 
PR-mode=3 - 

70 

CC Condition code indicating success or failure 

of the instruction execution. 

75 

DESCRIPTION: 

The Export Public Key instruction (1) translates an Internal Key Unit containing public key PU to an 
External Key Unit containing PU (PU-mode = 0) or (2) it constructs an External Key Unit for the internally 

20 stored key PUA (PU-mode = 1 ). 

The Export Public Key instruction has options for outputting the constructed External Key Unit (1) 
without a digital signature (PR-mode = 0), (2) with a digital signature generated with a PR supplied to the 
Export Public Key instruction (PR-mode = 2), or (3) with a digital signature generated with the internally 
stored key PRA (PR-mode = 3). The private key PR used with PR-mode = 2 can be a PRC, PRM, or PRU 

25 key. However, to generate a digital signature with private key PRC, the device must be configured as a 
certification center (i.e., CERTIFICATION = BT must be specified in the configuration vector). A hash-rule 
parameter indicates to the EPUK instruction the hash algorithm to be used in generating the digital 
signature. 

Control vectors C1 , C3, and C4 are all associated with the PU to be exported. C1 is stored either in 
30 IKU1 (PU-mode = 0) or in the PUACV register (PU-mode = 1). C4 is stored in EKU3, and C3 is an 
intermediate value used by the CFAP to request changes to C1 , as follows. When a PU is exported, the 
CFAP is permitted, in certain cases, to change control vector fields. If no change is desired or no change is 
permitted, then the CFAP sets C3 : = CI, else the CFAP produces C3 by making selected changes to CI. 
The control vector checking process assures that C3 is properly specified. Likewise, when a PU is exported 
35 the CF is permitted to change certain control vector fields. If no change is needed or prescribed, then the 
CF sets C4 : = C3; else the CF produces C4 by making selected changes to C3. 
The Export Public Key instruction executes only in the "run" state. 

FUNCTIONAL SPECIFICATION: 

40 

1. Perform input parameter consistency checking: 

a. Verify PR-mode has value 0, 2, or 3 

b. If PU-mode = 0, then verify that IKU1 is consistent to definition of an IKU 

c. If PR-mode = 2, then verify that IKU2 is consistent to definition of an IKU 
45 Continue if checking succeeds; otherwise set CC status flag and jump to step 9. 

2. Perform configuration vector and state vector checking: 

a. Verify that DEFINE(EPUK) in config. vector = B'1\ 

b. Verify that CF STATE in state vector is in the "run" state. 

c. Verify that ENABLE(EPUK) in state vector = BW. 

so d. Verify that KMP-FLAG(CKMP) in state vector is in the "full" state. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 9. 

3. Perform control block and control vector checking. Continue if checking succeeds; otherwise set CC 
status flag and jump to step 9. 

4. Construct outputs EKU3-length and EKU3, if PU-mode = 0: 
55 a. Set CKMP : = value of KMP in the CKMP register. 

b. Perform Recover Clear Key Unit on IKU1 to recover a clear key unit CKU1, using CKMP as the 
master key KMP. 

c. Construct control vector C4 from C3. 
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d. Construct an external key unit EKU3 and its length EKU3-length, from CKU1 and C4. 

5. Construct outputs EKU3-length and EKU3, if PU-mode = 1: 

a. Construct control vector C4 from C3. 

b. Construct SCB for an external key unit, from C4 and Environment ID. 

c. Construct external key unit EKU3 and its length EKU3-length, from the the key record of the PUA 
stored inside the CF and from the SCB. 

6. Produce outputs dsigl-length and dsigl, if PR-mode = 2: 

a. Extract control vector C from IKU2. 

b. Calculate a hash value on EKU3, using the hash algorithm specified by input hash-rule. 

c. Construct a cryptographic facility system signature record cfssrl from hash-rule and the calculated 
hash value. 

d. Calculate digital signature dsigl on the constructed cfssrl, using the private key stored in IKU2. 

7. Produce outputs dsigl-length and dsigl, if PR-mode = 3: 

a. Calculate a hash value on EKU3, using the hash algorithm specified by 

b. Construct a cryptographic facility system signature record from hash- rule and the calculated hash 
value. 

c. Calculate digital signature dsigl on the constructed cryptographic facility system signature record, 
using the private authenticator key stored inside the CF. 

8. Perform state vector update: None. 

9. Produce output CC from CC status flags. 

CONTROL BLOCK AND CONTROL VECTOR CHECKING: 

Perform control block and control vector checking: 

1. Extract SCB1 and C1 from IKU1, if PU-mode = 0: 

a. Extract the system control block SCB1 from IKU1. 

b. Extract control vector C1 from SCB1 . 

2. Extract C1 from PUACV register, if PU-mode = 1: 

a. Set C1 : = 16 byte control vector in the PUACV register. 

3. Extract SCB2 and C2 from IKU2, if PR-mode = 2: 

a. Extract the system control block SCB2 from IKU2. 

b. Extract control vector C2 from SCB2. 

4. Extract C2 from PRACV register, if PR-mode = 3: 

a. Set C2 : = 16 byte control vector in the PRACV register. 

5. Checking on C1 (associated with PU to-be-exported), if PU-mode = 0: 
a. Verify CV TYPE in C1 = B'11 10xxx' (i.e., a public PKA key) 

6. Checking on C1 (associated with PUA to-be-exported), if PU-mode = 1: none 

7. Checking on C2 (associated with PR), if PR-mode = 2: 

a. Verify CV TYPE in C2 = B'HHxxx 1 (i.e., a private PKA key) 

b. Verify EPUK usage bit = BT (i.e., enabled) 

c. Perform Control Vector Validate on C1 to validate certain fields in C1. 

8. Checking on C2 (associated with PRA), if PR-mode = 3: 
a. Verify EPUK usage bit = BT (i.e., enabled) 

9. Checking on C1 and C3: 
a. Verify C3 = C1. 

10. Checking on C2 and configuration vector: 

a. If CV TYPE in C2 = 'private certification key', then verify CERTIFICATION in config. vector = BT 
(i.e., certification center). 

11. (optional) Checking on SCB1, if PU-mode = 0: 

a. (optional) Verify that the current date and time is less than the expiration time Texp specified in 
SCB1. 

NOTE: : Tstart, Texp, and EID are checked only when an IKU is used. 

12. Checking on SCB2, if PR-mode = 2: 

a. Verify that the current date and time are in the time interval (Tstart.Texp), specified in SCB2 (i.e., 
Tstart £ DT < Texp). 

b. Verify that the Environment ID stored in the EID register is the same as the Environment ID stored 
in SCB2. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 9. 
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70 



75 



20 



Import Public key (IPUK) 

EQUATION: 

import-mode 

<MDC-mode> 

<MDC-index> 



/lb minimum/ 
/lb minimum/ 
/5b minimum/ 



<hash-rule> 



/3b minimum/ 



signature-mode /2b minimum/ 



EKD1- length 
EKU1 

<dsigl-length> 

<dsigl> 

<IKU2-length> 



/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 



; if import-mode-0 
; a) if import ~mode=0 & MDC-mode=0 
& EKU1 contains a PUC key 
b) if import -mode=0 & MDC-mode=l 
; a) if import -mode=0 & MDC-mode=0 
& BKU1 contains a PUC key 
b) if import -mode=0 & MDC-mode=l 



; if signature-mode-0 
; if signature-mode-0 
; if import -mode = 1 & signature-mode 



(0, 1) 



25 



30 



<IKU2> 
C3 
— > 

IKU3-length 

IKU3 

CC 



/unspecified/ ; if import-mode=l & signature-mode = (0, 1) 
/128b/ 

/16b/ 

/unspecified/ 
/unspecified/ 



35 

PARAMETER DEFINITIONS: 



40 



45 



50 



55 
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INPUTS DESCRIPTION 

IMPORT-MODE specifies the mode of public key import as 
follows: 

o import-mode=0 : The public key in EKU1 
is imported as a root PU. 

o import-mode=l : The public key in EKU1 
is imported as a successor PU. 

MDC-MODE Specifies the MDC processing mode, as follows: 

o MDC-mode=0 : If EKU1 contains a PUC key, 
then an MDC calculated on EKU1 is loaded 
into EKUMDC Table. (The EKUMDC Table 
entry must be uninitialized.) Otherwise, 
if EKU1 contains a PUA # PUM, or PUU key, 
no MDC is loaded. 

o MDC-mode=l MDC calculated on EKU1 is 
validated against an MDC value in the 
EKUMDC Table. (The EKUMDC Table entry 
must be preinitialized. ) 

The MDC-mode parameter is required when 
import-mode=0 . 
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NOTE: The hash-rule parameter specifies 
the hash algorithm to be used in calculating 
an MDC on EKU1. 

MDC- INDEX The MDC-index parameter specifies a number n 

= 0,1 ,...,16, where n refers to EKUMDC(n) . 

This parameter is required when (a) import- 
mode=0, MDC-mode-0, and EKU1 contains a PUC 
key, or (b) import-mode=0, MDC-mode=l. For 
case (a), MDC-index must be a value 0, 1, 

15. For case (b) , MDC-index must be a 
value 0, 15, when EKU1 contains a PUC 

key and MDC-index must be value 16 when EKU1 
contains a PUA, PUM, or PUU key. 

HASH-RULE Specifies the hash algorithm to be used to 

hash the External Key Unit EKU1. The 
encoding of the hash-rule is as follows: 

o hash-rule = 0 : MDC-2 algorithm 

o hash-rule = 1 : MDC -4 algorithm 

o hash-rule = 2 : MD4 algorithm 

o hash-rule « 3 : quadratic residue 

o hash-rule = 4-7 : reserved 

This parameter is required when (a) 
import-mode=0, MDC-mode=0, and EKU1 contains 
a PUC key, or (b) import -mode=0, MDC-mode=l. 

SIGNATURE-MODE Specifies the signature processing mode, as 
follows : 

o signature-mode=0 : system signature 
(checked by CF) 
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o signature -mode=l : application signature 

(checked by CFAP) 
o signature -mode=2 : no signature 

Signature-mode=2 may be specified only when 
import-mode=0 . That is, a public key 
imported with signature-mode=2 (no signature) 
must be a root PU. 



The following processing is indicated by 
f5 signature-mode and import-mode; 

1. For signature-mode=0 and import-mode=0, 
the system signature, dsigl, is verified by 

20 the CF using the PU in EKU1. 

2. For signature-mode=0 and import -mode=l, 
the system signature, dsigl, is verified by 

25 the CF using the PU in IKU2. 

3. For signature-mode=l and import-mode=0, 
an application signature is verified by the 
CFAP using the PU in EKU1. 

so 4# For signature-mode=l and import -mode=l, 

an application signature is verified by the 
CFAP using the PU in IKU2. 

35 

EKU1 -LENGTH The length of EKU1 in bytes. 

An External Key Unit containing the to-be- 
imported PU. For import-mode=0 , Texp in 
SCB1 must satisfy the relationship DT < 
Texp, where DT is the current date and time 
expressed in Coordinated Universal Time. 
This is because the to-be- imported PU is 
used to verify a 'weak 1 signature generated 
on EKU1. 



EKU1 

40 



45 



55 
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DSIG1 -LENGTH 



The length of dsigl in bits. This parameter 
is required only when signature-mode^O . 



DSIG1 



A digital signature produced from a CF 
System Signature Record (CFSSR) and a private 
key PR in accordance with section 6 of ISO 
DIS 9796. The CFSSR contains a 128-bit hash 
value calculated on EKU1. This parameter is 
required only when signature-mode=0 . 



I KU2 -LENGTH 



The length of IKU2 in bytes. This parameter 
is required only when import-mode=l and 
signature-mode=(0 or 1). 



IKU2 



An Internal Key Unit containing PU. The 
values of Tstart and Texp in SCB2 must satisfy 
the relationship Tstart < DT < Texp, where 
DT is the current date and time expressed in 
Coordinated Universal Time. This parameter 
is required only when import-mode=l and 
signature*-mode=(0 or 1). 



C3 



A 16 byte control vector for the to-be-im- 
ported PU. 



OUTPUTS 



DESCRIPTION 



IKU3 -LENGTH 



The length of IKU3 in bytes. 



IKU3 



An Internal Key Unit containing the imported 
PU. 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Import Public key instruction translates an External Key Unit containing a public key PU to an 
Internal Key Unit containing PU. The imported PU can be a PUA, PUC, PUM, or PUU. A PU imported with 
import-mode = 0 is called a "root" PU in a chain; a PU imported with import-mode = 1 is called a 
"successor" PU in a chain. 
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The External Key Unit can also have an attached digital signature (dsigl), which is validated using (1) 
the PU contained in the External Key Unit to be imported (import-mode = 0) or (2) a PU contained in an 
Internal Key Unit supplied to the Import Public key instruction (importmode = 1 ). The PU used to validate the 
attached digital signature can be a PUA, PUC, PUM, or PUU. 

5 A signature-mode parameter indicates whether a system signature is specified to the IPUK instruction 
(signature-mode = 0) or whether a system signature is not specified to the IPUK instruction (signature- 
mode = 1 and signature-mode = 2). signature-mode-1 indicates that an application signature is specified 
to, and checked by, the CFAP. signature-mode = 1 causes the IPUK instruction to execute exactly the same 
as signature-mode = 0, except that the step of validating the system signature is omitted. For example, when 

10 import-mode = 1 and signature-mode = 1 , history information is set in the control vector associated with IKU3 
using information in the control vector associated with 1KU2, even though the PU in IKU2 is not used to 
validate a system signature on EKU1. The IPUK instruction assumes that the CFAP uses the PU in IKU2 to 
validate an application signature on EKU1, and therefore the IPUK instruction uses IKU2 only to update 
IKU3 as a service to the CFAP. Likewise, when import-mode = 0 and signature-mode = 1 , the IPUK 

75 instruction assumes that the CFAP uses the PU in EKU1 to validate an application signature on EKU1, and 
therefore the IPUK instruction uses EKU1 only to update IKU3 as a service to the CFAP. On the other hand, 
signature-mode =2 indicates that no signature is specified to, and checked by, the CFAP. signature- 
mode =2 is valid only when import-mode = 0. Signature-mode = 2 can be specified only when a root PU is 
imported (i.e., when import-mode = 0 is specified). When signature-mode = 2, the IPUK instruction sets the 

20 HIST-CHAIN field = BW in the control vector of the imported public key (i.e., the imported PU key is 
always typed as a BRONZE key). 

A field in the configuration vector, designated SIG-COMPATIBILITY(IPUK), indicates whether dsigl is 
required (i.e., signified by SIG-COMPATIBILITY(IPUK) = B^) or whether dsigl is optional (i.e., signified by 
SIG-COMPATIBILITY(IPUK) = BT). For example, when signature-mode = 1 or signature-mode = 2 are 

25 specified, the IPUK instruction ensures that SIG-COMPATIBILITY(IPUK) = BT. 

When a device is configured to specify SIG-COMPATIBILITY(IPUK) = B'0\ the system signature 
attached to the External Key Unit is produced at an originating device (a) via an EPUK instruction, if the 
originating device is configured as an ordinary security module (i.e., INTERCHANGE field in configuration 
vector is B'0') or (b) via a GDS instruction, if the originating device is specifally configured as an 

30 interchange device (i.e., INTERCHANGE field in configuration vector is BT). Except when the originating 
device is an interchange device, the IPUK instruction executed at the receiving device ensures that an 
imported PUA key with HIST-CHAIN = 3 must hake originated with the same device as the PUM key used to 
validate the digital signature on that imported PUA key. 

For import-mode = 0, an MDC-mode parameter additionally specifies whether the imported External Key 

35 Unit is validated against an MDC value in the MDC Table stored in the CF Environment. MDCs stored in the 
MDC Table may be calculated using either MDC-2 or MDC-4 hash algorithm. An MDC-index parameter 
specifies which entry in the MDC Table is used for validating the imported EKU. if EKU Contains a PUC 
key, then MDC-index must have a value from 0 to 15, inclusive. If EKU contains a PUA, PUM, or PUU key, 
then MDC-index must have a value of 16. However, if importmode = 0, MDC-mode = 0, and EKU contains a 

40 PUC key, then the IPUK instruction performs as follows: (1) MDC-index is set equal to the value of DOMAIN 
ID in the PUC control vector, (2) it is verified that EKUMDC FLAG(M DC-index) = BW, (3) an MDC is 
calculated on EKU and stored in EKUMDC(MDC-index), and (4) EKUNDC FLAG(MDC-index) is set equal to 
B'01\ The IPUK processing rules ensure that one and only one PUC key can be imported for each domain 
(DOMAIN ID). 

45 Control vectors C1 , C3, and C4 are all associated with the PU to be imported. C1 is stored in EKU1 , C4 
is stored in IKU3, and C3 is an intermediate value used by the CFAP to request changes to C1, as follows. 
When a PU is imported, the CFAP is permitted, in certain cases, to change control vector fields. If no 
change is desired or no change is permitted, then the CFAP sets C3 := C1, else the CFAP produces C3 by 
making selected changes to C1. The control vector checking process assures that C3 is properly specified. 

50 Likewise, when a PU is imported the CF is permitted to change certain control vector fields, e.g., to record 
import "history" about PU. If no change is needed or prescribed, then the CF sets C4 : = C3; else the CF 
produces C4 by making selected changes to C3. 

The fundamental strategy followed in key import is to freely permit, rather than restrict, the key import 
process-except that all relevant history and actions pertaining to the key and to the key import process are 

55 recorded in the control vector of the imported key. Thereafter, when the key is used, the "history" 
information in the control vector is be tested to ensure that it meets whatever minimum standard has been 
set forth. For example, when used together with a private key in one of the key management instructions, 
such as a GKSP or !DK instruction, the logged "history" information in the control vector of the public key 
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must be at least as great as the threshold information that has been encoded Into the control vector of the 
private key at the time of key generation via the GPUPR instruction. 
The Import Public key instruction executes only in the "run" state. 

5 FUNCTIONAL SPECIFICATION: 

1 . Perform input parameter consistency checking: 

a. If import-mode = 0, then verify MDC-mode = 0 or 1 b. If import-mode = 0 and MDC-mode = 1, then 
verify 0 Z MDC-index S 16. 
jo c. Verify that EKU1 is consistent to definition of an EKU. 

d. If import-mode = 1 , then verify that IKU2 is consistent to definition of an EKU. 

e. If import-mode = 0, verify that signature-mode = 0, 1 or 2. 

f. Else (import-mode = 1) verify signature-mode = 0 or 1. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 
75 2. Perform configuration vector and state vector checking: 

a. Verify that CF STATE in state vector is in the "run" state. 

b. Verify that KMP-FLAG(CKMP) in state vector is in the "full" state. 

c. Verify that DEFINE(IPUK) in config. vector = B'V. 

d. Verify that ENABLE(IPUK) in state vector = BW. 

20 e. If import-mode = 0 and MDC-mode = 1, then verify EDUMDC FLAG(MDC-index) in state vector > 

BW. 

f. If signature-mode = 1 or signature-mode = 2, then verify that SIG-COMPATIBILITY(IPUK) in config. 
vector = BT. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 
25 3. Perform control block and control vector checking. Continue if checking succeeds; otherwise set CC 
status flag and jump to step 13. 

4. Calculate MDC on EKU3, using the hash algorithm specified by input hash-rule, if import-mode = 0 and 
MDC-mode = 1. 

5. Initialize MDC Table entry, if import-mode = 0 and MDC-mode =0 and EKU1 contains a PUC key: 
30 If import-mode = 0 and MDC-mode = 0, then do: 

a. Extract the system control block SCB1 from EKU1. 

b. Extract the control vector C1 from SCB1 . 

c. If CV TYPE in C1 = 'PUC, then do: 
1) Verify 0 =< MDC-index =< 15. 

35 2) Set X : = value of DOMAIN ID in C1 (i.e., 0 to 15) 

3) Verify X = MDC-index 

4) Verify EKUMDC FLAG( MDC-index) in state vector = BW. 

5) Continue if all of the above checking succeeds; otherwise set CC status flag and jump to step 
13. 

40 6) Calculate MDC on EKU1, using the hash algorithm specified by input hash-rule. 

7) Set EKUMDC FLAG(M DC-index) in state vector := B'01\ 

8) Set EKUMDC(MDC-index) in MDC Table := MDC (i.e., MDC calculated above) 

6. Validate MDC if import-mode = 0 and MDC-mode = 1: 

a. Set MDC-of-reference := EKUMDC(MDC-index) in MDC Table 
45 b. Verify MDC-of-reference = MDC (calculated above) 

Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 

7. Construct expected record-codel to be referenced against record-code stored in cfssrl , if signature- 
mode =0: 

a. If import-mode = 0, then extract control vector C from EKU1. 
so b. If import-mode = 1, then extract control vector C from IKU2. 

c. Construct record-codel from control vector C. 

8. Recover and validate cfssrl , if signature-mode = 0: 

a. If import-mode = 0, then recover cryptographic facility system signature record cfssrl from from 
digital signature dsigl, using the public key stored in EKU1. 
55 b. If import-mode = 1 , then recover cryptographic facility system signature record cfssrl from from 

digital signature dsigl , using the public key stored in IKU2. 

c. Verify that cfssrl is consistent to definition of a cryptographic facility system signature record. 

d. Extract hash rule hash-rule 1 from cfssrl . 
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e. Verify that record-code stored in cfssrl is the same as record-codel . 
Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 
9. Calculate hash value MDC1 on EKU1 using the hash algorithm specified by hash-rulel, if signature- 
mode = 0. 

5 10. Validate MDC1 against reference MDC1 in cfssrl, if signature-mode = 0: 

a. Extract the hash value stored in the hash field in cfssrl . 

b. Verify that MDC1 is the same as the extracted hash value. 

Continue if verification succeeds; otherwise set CC status flag and jump to step 13. 
11. Construct outputs IKU3-length and IKU3: 
w a. If import-mode = 0, then set C2 := CI 

b. Set C4 := C3 and update history information (HIST-IPUK, HIST-CHAIN, HIST-MDC, HIST-DOMAIN 
ID, and HIST-KREGMODE) in C4, using the Control Vector Generate. 

c. Replace the value of the control vector stored in EKU1 with C4. 

d. Construct a key authenticator record karl from the key record in EKU1, using the method specified 
75 in Key Record Encrypt Algorithm 12. 

e. Construct a clear key unit CKU1 from EKU1 and karl. 

f. Set CKMP := value of KMP stored in the CKMP register. 

g. Perform Encipher Clear Key Unit On CKU1 to obtain an internal key unit IKU3, using CKMP as the 
master key KMP. 

20 12. Perform state vector update: None. 

13. Produce output CC from CC status flags. 

CONTROL BLOCK AND CONTROL VECTOR CHECKING: 

25 Perform Control block and control vector checking: 

1. Extract SCB1 and C1 from EKU1: 

a. Extract the system control block SCB1 from EKU1. 

b. Extract control vector C1 from SCB1 . 

2. Extract SCB2 and C2 from IKU2, if import-mode-1 : 
30 a. Extract system control block SCB2 from IKU2. 

b. Extract control vector C2 from SCB2. 

3. Checking on C1 (associated with PU to-be-imported): 

a. Verify CV TYPE in C1 = BMHOxxx' (i.e., a public PKA key) 

b. If import-mode = 0 and MDC-mode = l, then do: 

35 1) If CV TYPE in C1 = 'PUC\ then verify MDC-index = DOMAIN ID in C1 (i.e., a value 0 to 15). 

2) If CV TYPE in C1 * •PUC then verify MDC-index = 16. 
NOTE: For import-mode =0, IPUK usage is not checked since the use of PU to validate a 'weak' 
signature is always implied. 

4. Checking on C2, if import-mode = 0 none 

40 NOTE: The IPUK usage bit is not checked for import-mode = 0, since the usage in this case is implied. 

5. Checking on C2 (associated with PU used to validate signature), if import-mode = 1 : 

a. Verify CV TYPE in C3 = B'mOxxx' (i.e., a public PKA key) 

b. Verify IPUK usage bit in C2 = BT (i.e., enabled) 

c. Perform Control Vector Validate on C2 to validate certain fields in C2. 
45 6. Checking on C1 and C3: 

a. Verify C3 = C1 

NOTE: there are currently no fields in C1 that may be altered by CFAP. 

7. (optional) Checking on SCB1, if import-mode = 0: 

a. (optional) Verify that the current date and time is less than the expiration time Texp specified in 
50 SCB1. 

NOTE: : Tstart, Texp, and EID are checked only when an IKU is used. 

8. Checking on SCB1, if import-mode = 1 (i.e., when PU is the key being imported): no checking 
required. 

9. Checking on SCB2, if import-mode = 1 (i.e., when PU is used to verify a 'strong* signature): 

55 a. Verify that the current date and time are in the time interval (Tstart.Texp), specified in SCB2 (i.e., 

Tstart =< DT< Texp). 
Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 
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70 



75 



In the above checking steps, it should be noted that import-mode = 1 implies that (1) signature-mode = 0 
or signature-mode = 1 and that (2) an IKU2 is specified to the IPUK instruction. 

Import Private Key (IPRK) 



EQUATION: 

Input-source 
<EKUl-length> 

<EKU1> 

— > 

IKU2- length 

IKU2 

CC 



/lb minimum/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/unspecified/ 



; if input-source=0 
; if input-source=0 



20 PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 

INPUT-SOURCE The input-source parameter specifies the 
25 source of EKUl-length and EKU1, as follows: 

o input-source=0 : instruction input 
30 o input-source=l : EKU buffer in CF 

Environment 
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EKU1 -LENGTH 



The length of EKU1 in bytes. This input is 
required if input- source = 0. 



EKU1 



70 



15 



An External Key Unit containing the to-be- 
imported PR. This input is required if 
input-source = 0. The value of EID in SCB1 
must equal the value in the EID register. 
The value of Texp in SCB1 must satisfy the 
relationship DT < Texp, where DT is the 
current date and time expressed in Coordi- 
nated Universal Time. 



OUTPUTS 



DESCRIPTION 



20 



25 



I KU2 -LENGTH 

IKU2 

CC 



The length of IKU2 in bytes. 

An Internal Key Unit containing the imported PR. 

Condition code indicating success or failure 
of the instruction execution. 



30 



35 



40 



DESCRIPTION: 

The Import Private Key instruction translates an External Key Unit EKU1 containing a PRU key to an 
Internal Key Unit containing the PRU. An input source parameter indicates whether EKU1 is supplied as a 
parameter input to the Import Private Key instruction or whether it is read from the EKU buffer in the CF 
Environment. An EKU1 read from the EKU buffer must be loaded into the CF via a protected interface, e.g., 
a smart card reader. 

The EID field in the System Control Block (SCB) of EKU1 must be initialized with 16 ASCII 'O's or with a 
value equal to the value stored in the EID register of the CF (i.e., the EID value originally set using an LPID 
instruction). 

The Import Private Key instruction executes only in the "run" state. 



Generate Key Set PKA (GKSP) 

45 EQUATION: 
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proce SB-mode 



/2b minimum/ 



70 



75 



20 



25 



30 



domain- id 


/4b/ 


r 


if 


process-mode= ( 0 


or 


1) 






key-management-protocol 


/lb minimum/ 


S 


if 


procees-mode= ( 0 


or 


1) 






<key-management-mode> 


/lb minimum/ 


t 


if 


proceBB-mode= ( 0 


or 


1] 


9 


key-manage- 










ment-protocol=l 










<PR-mode> 


/lb minimum/ 


i 


if 


proce es-mode= ( 0 


or 


2) 






<hash-rule> 


/3b minimum/ 


; 


if 


proce BB-mode= ( 0 


or 


2) 


9 


PR-mode=l 


<IKU1-Iength> 


/16b/ 


* 


if 


proce BS-mode= ( 0 


or 


2) 






<IKU1> 


/unspecified/ 




if 


proce b B-mode= ( 0 


or 


2 \ 






<IKU2-length> 


/16b/ 


* 


if 


process-mode^ ( 0 


or 


2 \ 


9 


*%y> a ■« 

PR— mode= 1 


<IKU2> 


/unspecified/ 


; 


if 


process-mode^ ( o 


or 


2 , 


9 


PR— mode =1 


<ticket-in> 


/64b/ 


? 


if 


proce s s-mode= 2 










<C3> 


/128b/ 


; 


if 


process— mode= ( 0 


or 


1 J 






<C4> 


/128b/ 


; 


if 


proce B8-mode= ( 0 


or 


1 \ 






— > 

<e*KM.C4(KKL)> 


/64b/ 


; 


if 


proce BB-mode= ( 0 


or 


1) 






<e*KM.C5(KKR)> 


/64b/ 


; 


if 


proce B6-mode= ( 0 


or 


1) 






<keyblk-length> 


/16b/ 




if 


proce s s-mode= ( 0 


or 


2) 






<ePUM(keyblk)> 


/unspecified/ 


» 


if 


proce b s-mode= ( 0 


or 


2] 






<dsigl-length> 


/16b/ 


; 


if 


proce BB-mode= ( 0 


or 


2) 


t 


PR-mode «1 


<deigl> 


/unspecified/ 


; 


if 


process-mode^ ( 0 


or 


2) 


9 


PR-mode^ 1 


<ticket-out> 


/64b/ 


# 


if 


proce BS-mode=l 










CC 


/unspecified/ 

















PARAMETER DEFINITIONS: 
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INPUTS 



DESCRIPTION 



PROCESS-MODE specifies the instruction processing mode, 
as follows: 

o process -mode=0 : produce outputs from 
inputs 

o process -mode=l : produce intermediate 

outputs from inputs 
o process-mode=2 : produce outputs from 

intermediate outputs 

DOMAIN- ID The domain- id parameter specifies a domain 

identifier that ranges from 0 to 15. When C3 
and C4 are 64 bit control vectors (EXTENSION 
= B'OO'), a value of domain-id=0 must be 
specified. This parameter is required only 
when process-mode=(0 or 1). 

KEY-MANAGEMENT-PROTOCOL 

The key-management-protocol parameter 
specifies the protocol used for key manage- 
ment, as follows: 

o key-management-protocol=0 : private 
protocol 

o key-management-protocol=l : certifica- 
tion center protocol 

This parameter is required only when process- 
mode^ 0 or 1) . 



KEY-MANAGEMENT-MODE 

The key-management -mode parameter specifies 
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the method (called mode) used to register a 
public key management key with the certifica- 
tion center , as follows: 

o key-management -mode=0 : key registration 

is performed using mode 0 
o key-management-mode=l : key registration 

is performed using mode 1 

The CF does not define the meaning of modes 
0 and 1. These modes are defined on the basis 
of the network key management architecture, 
and (as far as the CF is concerned) can be 
whatever a customer wants them to be. This 
parameter is required only when process- 
mode^ 0 or 1) and key-management-protocol=l . 



25 PR-MODE The PR-mode parameter specifies whether a 

digital signature is generated and, if so, 
then also the source of PR. 



30 o PR-mode=0 : no 

o PR-mode=l : yes, use PR in IKU2 



This parameter is required only when process- 
mode^ or process-mode=2 . 



HASH-RULE Specifies the hash algorithm to be used to 

40 calculate a hash value on ePUM(keyblk) . The 

encoding of the hash-rule is as follows: 



o 


hash- 


•rule = 


0 : 


MDC-2 algorithm 


o 


has h- 


-rule = 


1 : 


MDC-4 algorithm 


o 


hash- 


•rule = 


2 : 


MD4 algorithm 


o 


hash- 


-rule = 


3 : 


quadratic residue 


o 


hash- 


•rule = 


4-7 


: reserved 
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This parameter is required only when process- 
mode=(0 or 2) and PR-mode=l. 



IKU1 -LENGTH 



The length of IKU1 in bytes. 



This parameter is required only when process- 
mode=(0 or 2) . 



IKU1 



An Internal Key Unit containing a PUM of 
another device and belonging to domain-id. 
The value of EID in SCB1 must not equal the 
value in the EID register. The values of 
Tstart and Texp in SCB1 must satisfy the 
relationship Tstart < DT < Texp, where DT is 
the current date and time expressed in 
Coordinated Universal Time. 



This parameter is required only when process- 
mode^ 0 or 2) . 



I KU2 -LENGTH 



The length of IKU2 in bytes. This parameter 
is required only when process-mode=(0 or 2) 
and PR-mode=l. 



IKU2 



An Internal Key Unit containing a PRM of 
this device and belonging to domain- id. The 
value of EID in SCB2 must equal the value in 
the EID register. The values of Tstart and 
Texp in SCB2 must satisfy the relationship 
Tstart =< DT < Texp, where DT is the current 
date and time expressed in Coordinated 
Universal Time. This parameter is required 
only when process -mode=(0 or 2) and PR-mode=l. 



TICKET-IN 



An 8-byte value that must be equal to the 
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8-byte value stored in the GKSP-Ticket 
register in the CF. This parameter is 
required only when process-mode=2 . 



C3 



A 16-byte control vector associated with the 
leftmost 64 bits of the key-encrypting 
receiver key KK to be exported to a receiving 
cryptographic system. For process-mode=0, C3 
MUST be equal to the control vector stored 
in keyblk of output parameter ePUM(keyblk) . 
See control vector checking for a specifica- 
tion of C3. This parameter is required only 
when process -mode=(0 or 1). 



C4 



A 16-byte control vector associated with 
KKL, where KKL is the leftmost 64 bits of 
the key-encrypting sender key KK to be 
retained at the generating cryptographic 
system. This parameter is required only 
when process-mode=(0 or 1). 



OUTPUTS 



DESCRIPTION 



E*KM.C4 (KKL) 



64 bit key KKL enciphered under 128 bit 
master key KM and 128 bit control vector C4. 
KKL is the left half of a 128 bit key-encrypt- 
ing key. This parameter is produced only 
when process-mode=(0 or 1). 



E*KM.C5(KKR) 



64 bit key KKR enciphered under 128 bit 
master key KM and 128 bit control vector C5. 
KKR is the right half of a 128 bit key-encrypt- 
ing key. This parameter is produced only 
when process-mode=(0 or 1). 



KEYBLK-LENGTH The length of keyblk and ePUM( keyblk) in 
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bits. This parameter is produced only when 
process -mode=(0 or 2). 



EPUM ( KEYBLK ) 



keyblk encrypted with public key PUM of 
another device. For process -mode=0, keyblk 
is a key block produced from a Crypto Facili- 
ty DEA Key Record (CFDKR) . For process- 
mode^ 1 or 2), keyblk has an unspecified 
format. This parameter is produced only 
when process -mode=(0 or 2). 



DS I G 1 - LENGTH 



The length of dsigl in bits. This parameter 
is produced only when process-mode=(0 or 2) 
and PR-mode=l. 



DSIG1 



A digital signature produced from a CF 
System Signature Record (CFSSR) and a 
private key management key PRM of this 
device, in accordance with section 6 of ISO 
DIS 9796. The CFSSR contains a 128-bit hash 
value calculated on ePUM(cfbdkbl) . This 
parameter is produced only when process- 
mode^ 0 or 2) and PR-mode=l. 



TICKET-OUT An 8-byte value equal to an 8-byte value 

stored in the GKSP-Ticket register in the 
CF. This parameter is produced only when 
process -mode=l . 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Generate Key Set PKA instruction generates two encrypted copies of a 128-bit key-encrypting key, 
KK = (KKL, KKR), where KKL and KKR are the left and right 64-bit parts of KK. The first copy, which is 
encrypted with the master key, is for local use at the generating device. The second copy, which is 
encrypted with a public key management key, is distributed to a receiving device where it is imported with 
and IDK instruction. At the generating device, KK is designated (via a control vector) to be a key- encrypting 
sender key with a 'GKS OP-EX 1 attribute. At the receiving device, KK is designated (via a control vector) to 
be a key-encrypting receiver key with an 'RTMK' attribute. (When the receiving device does not implement 
PKCD or control vectors, KK usage must be controlled via other means.) The EXPORT CONTROL field in 
the control vectors associated with KK must also specify 'no export/ 
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The first encrypted copy of KK has the form e*KM.C4(KKL), e*KM.C5(KKR), where e*KM.C4(KKL) and 
e*KM.C5(KKR) are the encrypted left and right 64-bit parts of KK, respectively. KM.C4 and KM.C5 are 
variant keys formed as the Exclusive-OR product of master key KM and control vectors C4 and C5, 
respectively. C4 and C5 are control vectors associated with KKL and KKR, respectively. The second 
encrypted copy of KK has the form ePUM(keyblk), where PUM is the public key management key of the 
receiving device and keyblk is a key block containing KK. 

A process-mode parameter provides different processing options within the GKSP instruction. When 
process-mode = 0 is specified, keyblk is key block produced from a Crypto Facility DEA Key Record 
(CFDKR). The format of the CFDKR and the algorithm for producing keyblk from CFDKR are rigidly defined 
by PKCD. Process-modes 1 and 2 permit a keyblk with unspecified format to be processed. This is 
accomplished by invoking the GKSP instruction with process-mode = 1 to produce a CFDKR stored within 
the CF, then invoking a Translate-from-CFDKR instruction which translates CFDKR to a specified key block 
(keyblk) also stored within the CF, and finally invoking the GKSP instruction with process-mode = 2 to take 
the so-translated keyblk and encrypt it with the public key management key, PUM, of the receiving device. 
The aim of process-modes 1 and 2 is to remove the translation step from the GKSP instruction, so that the 
GKSP instruction need not directly implement a host of different possible translation options for compatibil- 
ity with other non-PKCD devices. A significant advantage can be achieved if the Translate-from-CFDKR 
instruction is implemented within a programmable memory within the CF. 

The Generate Key Set PKA instruction has options for generating a system signature, dsigl, on output 
ePUM(keyblk) (PR-mode = 1) or not generating a system signature on output ePUN(keyblk) (PR-mode = 0). 
When PR-mode = 1 is specified, a private key management key, PRM, belonging to the sending device is 
used to generated the system signature. A hash-rule parameter indicates to the GKSP instruction the hash 
algorithm to be used in generating the digital signature. 

The Generate Key Set PKA instruction executes only in the "run" state. 

FUNCTIONAL SPECIFICATION: 

1. Verify process-mode = 0, 1, or 2. If verification fails, set CC status flag and jump to step 13. 

2. Validate ticket-in, and extract fields from CF Environment, if process- mode = 2: 
30 If process-mode = 2 then do: 

a. Verify GKSP Buffer Flag in CF Environment = 2 or 3. If verification fails then set CC status flag and 
jump to step 13 

b. Verify ticket-in : = value stored in GKSP Ticket field in CF Environment. If verification fails then set 
CC status flag and jump to step 13 

35 c. Set domain-id : = bits 00..03 of GKSP Save field in CF Environment 

d. Set key-management-protocol ; = bit 04 of GKSP Save field in CF Environment 

e. Set key-management-mode : = bit 05 of GKSP Save field in CF Environment. 

3. Perform input parameter consistency checking if process-mode = 0 or 2: 
If process-mode = 0 or process-mode = 2 then do: 

40 a. Verify PR-mode = 0 or 1 

b. Verify that IKU1 is consistent to definition of an IKU. 

c. If PR-mode = 1 , then verify that IKU2 is consistent to definition of an IKU. 
Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 

4. Perform configuration vector and state vector checking: 
45 a. Verify that DEFINE(GKSP) in config. vector = BT. 

b. If key-management-protocol = 1. then KMGT PROTOCOL in config. vector = B'1V or B'10\ 

c. If key-management-protocol = 1 and key-management-mode = 0, then KREG in config. vector = 
B'0\ 

d. If key-management-protocol = 0, then KMGT PROTOCOL in config. vector = B'1V or B'OV. 
50 e. Verify that CF STATE in state vector is in the "run" state 

f. Verify that KMP-FLAG(CKMP) in state vector is in the "full" state. 

g. Verify that CKM FLAG in state vector is in the "full" state. 

h. (optional) Verify LPID FLAG in state vector is in the "full" state. 

i. Verify that ENABLE(GKSP) in state vector = B'00\ 

55 Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 

5. Perform control block and control vector checking. Continue if checking succeeds; otherwise set CC 
status flag and jump to step 13. 
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6. Construct a record code record-codel for cfdkrl based on parameters key- management-protocol and 
key-management-mode, if process-mode = 0 or process-mode = 1 . 

7. Construct cfdkrl if process-mode = 0 or process-mode - 1 : 

a. Generate a 128-bit random key KK consisting of a 64-bit left half KKL and a 64-bit right half KKR. 
5 b. Adjust parity of KK to odd parity 

c. Set EID : = contents of the EID register in CF Environment. 

d. Construct the cryptographic facility DEA key record cfdkrl based on KK, EID, C3, and record- 
codel . 

8. Produce outputs e*KM.C4(KKL) and e*KM.C5(KKR) if process-mode = 0 or process-mode = 1: 
w If process-mode = 0 or process-mode = 1 then do: 

a. Set KM : = contents of CKM Register in the CF Environment. 

b. Exclusive-OR KM to C4 and use the resulting key to encrypt KKL. 

c. Set C5 := C4 and invert the values in bits 41 and 42 in C5 (i.e., adjust the KEY FORM field in C5). 

d. Exclusive-OR KM to C5 and use the resulting key to encrypt KKR. 

75 9. Produce output ticket-out and store parameter values in CF Environment if process-mode = 1: 
If process-mode = 1 then do: 

a. Generate a 64-bit random number and assign it to ticket-out. 

b. Save parameter values in CF Environment: 

1) Set GKSP Ticket field in CF Environment := ticket-out 
20 2) Set GKSP Save field in CF Environment := domain-id || key-management-protocol [| key- 

management-mode || BW 

3) Set GKSP Buffer Flag in CF Environment := 1. 

4) Set GKSP Buffer field in CF Environment := 416-bit cfdkrl (left- justified in GKSP Buffer field). 

5) Set GKSP Record Length field in CF Environment := 416 

25 6) Set GKSP Buffer Length field in CF Environment : = value of GKSP-buffer-length in Configura- 

tion Table. 

10. Produce outputs keyblk-length and ePUM(keyblk) if process-mode = 0 or process-mode = 2: 

a. If process-mode = 0 then do: 
1) Set key-process = 1 

30 2) Set cfdkrl -length : = 41 6 

b. If process-mode = 2 then do: 

1) Set key-process : = value of GKSP Buffer Flag in CF Environment -2 r Set key-process := 0, if 
GKSP Buffer Flag = 2 Vf Set key-process : = 1, if GKSP Buffer Flag ==3 7 

2) Set cfdkrl -length : = value stored in GKSP Record Length field in CF Environment 
35 3) Set cfdkrl : = the leftmost cfdkrl -length bits of value stored in GKSP-buffer. 

c. Construct an encrypted DEA key block ePUM(keyblk), from cfdkrl, using the public key PUM 
stored in IKU1 . Note: keyblk-length is also produced by this step. 

11. Produce outputs dsigl-length and dsigl, if (process-mode = 0 or process- mode = 2) and if PR- 
mode = 1 : 

40 a. Extract 16-byte control vector C from IKU2 

b. Construct record-code to be stored in a cryptographic facility system signature record, based on 
control vector C. 

c. Calculate a hash value on ePUM(keyblk), using the hash algorithm specified by input hash-rule. 

d. Construct a cryptographic facility system signature record cfssrl from hash-rule, record-code, 
45 and the calculated hash value. 

e. Calculate digital signature dsigl on the constructed cfssrl, using the private key stored in IKU2. 

12. Reset CF Environment parameters if process-mode = 2: 
If process-mode = 2 then do: 

a. Set GKSP Ticket field in CF Environment := 8 XW 
so b. Set GKSP Save field in CF Environment : = XW 

c. Set GKSP Buffer Flag in CF Environment : = 0. 

13. Produce output CC from CC status flags. 

CONTROL BLOCK AND CONTROL VECTOR CHECKING: 

55 

Perform control block and control vector checking: 

A Perform the checking in steps 1 , 2, and 3, if process-mode = 0 Or process-mode = 1 : 
1. Checking on C3 (associated with KKL sent to receiver) 
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a. CV TYPE in C3 = 'Key-Encrypting Receiver Key 1 

b. Verify RTMK in C3 = BT (i.e.. enabled) 

c. Verify XLTKEY-in in C3 = B'0' (i.e.. disabled) 

d. Verify GKS in C3 = B'000' (i.e., disabled) 

5 e. Verify EXPORT CONTROL in C3 = B'0' (i.e., export via RFMK not permitted) 

f. If EXTENSION in C3 = BW, then verify domain-id (in instruction) = 0 

g. Verify KEY FORM = B'010' or B*110' (i.e., KKL) 

h. Verify EXTENSION in C3 = BW or B'01\ 

i. If EXTENSION in C3 = BW. then do: 

70 1) Verify C3R = C3L (i.e.. CV EXTENSION = CV BASE) 

2) Verify domain-id (in instruction) = 0 
j. If EXTENSION in C3 = B'OV, then do: 

1) Verify DOMAIN ID in C3 = domain-id (in instruction). 

2) Verify HIST-GKSP/IDK field in C3 = BT 

75 2. Checking on C4 (associated with KKL retained by sender): 

a. CV TYPE in C4 = •Key-Encrypting Sender Key* 

b. Verify GKS in C4 = B'11V (i.e., enabled) 

c. Verify RFMK in C4 = B'0* (i.e., disabled) 

d. Verify XLTKEY-out in C4 = B'0' (i.e., disabled) 

20 e. Verify EXPORT CONTROL in C4 = B'0' (i.e., export via RFMK not permitted) 

f. If EXTENSION in C4 = BW, then do: 

1) Verify C4R = C4L (i.e., CV EXTENSION = CV BASE) 

2) Verify domain-id (in instruction) = 0 

3. Checking on C3 and C4: 

25 a. Verify KEY FORM in C4 = KEY FORM in C3. 

b. Verify EXTENSION in C4 = EXTENSION in C3. 

c. If LOG INDICATOR in C3 = 1 then LOG in C3 = USAGE in C4 (i.e. C3(50..54) = C4(18..22) 

d. If LOG INDICATOR in C4 = 1 then LOG in C4 = USAGE in C3 (i.e. C4(50..54) = C3(18..22) 

e. If EXTENSION = B'0V, then verify C4R = C3R 

30 Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 

B Perform the checking in steps 4, 5 10, if process-mode = 0 or process-mode = 2: 

4. Extract SCB1 and C1 from IKU1: 

a. Extract system control block SCB1 from IKU1. 

b. Extract control vector C1 from SCB1 . 

35 5. Extract SCB2 and C2 from IKU2, if PR-mode = 1 

a. Extract system control block SCB2 from IKU2. 

b. Extract control vector C2 from SCB2. 
6. Checking on C1 (associated with PUM): 

a. Verify CV TYPE in C1 = 'public key management key' 
40 b. Note: checking on CV TYPE EXTENSION has been deleted. 

c. Verify GKSP usage in C1 = BT (i.e., enabled) 

d. Verify HIST-IPUK = B'V (i.e., imported) 

e. Verify DOMAIN ID in C1 = domain-id (in instruction) 

f. If key-management-protocol (in instruction) = B'V (i.e., 'certification center protocol'), then do: 
45 1) If key-management-mode (in instruction) = 0, then KREGMODE in C1 = B'OT. 

2) If key-management-mode (in instruction) = 1, then KREGMODE in C1 = B'10\ 

3) Verify HIST-CHAIN in C1 = 2. 

g. Perform Control Vector Validate on C1 to validate certain fields in C1 . 

h. Verify HIST-MDC in CI > = FLOOR-MDC in configuration vector, 
so 7. Checking on C2 (associated with PRM), if PR-mode = 1: 

a. Verify CV TYPE in C2 = 'private key management key' 

b. Verify GKSP in C2 = B'V fi e., enabled) 

c. Verify DOMAIN ID in C2 = domain-id (in instruction) 

d. Perform Control Vector Validate on C2 to validate certain fields in C2. 
55 e. Verify RC2 = 0 

8. Checking on C1 and C2 (associated with PUM and PRM), if PR-mode = 1: 

a. Verify HIST-MDC in C1 > = THRES-MDC in C2. (This check is valid for private protocols and 
certification center protocols.) 
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b. Note: checking on CV TYPE EXTENSION has been deleted. 

9. Checking on SCB1: 

a. Verify that the current date and time are in the time interval (Tstart,Texp), specified in SCB1 (i.e., 
Tstart =< DT< Texp). 

b. Verify that the Environment ID stored in the EID register is not the same as the Environment ID 
stored in SCB1. 

10. Checking on SCB2, if PR-mode = 1 : 

a. Verify that the current date and time are in the time interval (Tstart.Texp), specified in SCB2 (i.e., 
Tstart =< DT< Texp). 

b. Verify that the Environment ID stored in the EID register is the same as the Environment ID 
stored in SCB2. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 13. 
Import DEA Key (IDK) 
EQUATION: 



process-mode 



/2b minimum/ 



domain- id /4b/ 
key-management-protocol /lb minimum/ 
<key-management-mode> /lb minimum/ 



<IKUl-length> 
<IKD1> 

<IKU2-length> 
<IKU2> 

<keyb lk- lengt h> 
<ePUM(keyblk)> 
<deigl-length> 
<daigl> 

<ticket-in> 

<sender-EID> 

<C3> 

<C4> 

— > 

<e*KM.C5(KKL)> 
<e*KM.C6(KKR)> 
<ticket-out> 
CC 



/16b/ 



/unspecified/ ; if 



/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 

/64b/ 
/128b/ 
/128b/ 
/128b/ 

/64b/ 
/64b/ 
/64b/ 

/unspecified/ 



; if process-mode=(0 or 1) 

; if process-mode=(0 or 1) 

; if proces8-mode=(0 or 1), key-man- 
agement-protocol =1 

; if process-mode=(0 or 1) , dsigl- 
length>0 

process-mode- (0 or 1), dsigl- 
length>0 
; if process-mode=(0 or 1) 
; if procees-mode= ( 0 or 1) 
; if process-mode=(0 or 1) 
; if process-mode=(0 or 1) 
; if proces s -mode = ( 0 or 1) 
; if process-mode=(0 or 1) , dsigl- 

length>0 
; if process-mode=2 
; if process-mode=(0 or 2) 
; if process-mode=(0 or 2) 
; if proces8-mode= ( 0 or 2) 



; if process-mode=(0 or 2) 
; if proces s-mode= ( 0 or 2) 
; if process-mode=l 



PARAMETER DEFINITIONS: 
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INPUTS DESCRIPTION 

PROCESS-MODE specifies the instruction processing mode, 
5 as follows: 

o process -mode=0 : produce outputs from 
inputs 

o process -mode=l : produce intermediate 
outputs from inputs 

75 



20 



25 



30 



35 



40 



45 



50 



55 
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o process -mode=2 : produce outputs from 
intermediate outputs 

DOMAIN-ID The domain-id parameter specifies a domain 

identifier that ranges from 0 to 15. When C3 
and C4 are 64 bit control vectors (EXTENSION 
= B'OO 1 )/ a value of domain-id=0 must be 
specified. This parameter is required only 
when process-mode-(0 or 1). 

KEY-MANAGEMENT-PROTOCOL 

The key-management-protocol parameter 
specifies the protocol used for key manage- 
ment, as follows: 

o key-management-protocol=0 : private 
protocol 

o key-management-protocol=l : certifica- 
tion center protocol 

This parameter is required only when process- 
mode^ 0 or 1) . 

KEY-MANAGEMENT-MODE 

The key-management -mode parameter specifies 
the method (called mode) used to register a 
public key management key with the certifica- 
tion center, as follows: 

o key-management-mode=0 : key registration 

is performed using mode 0 
o key-management-mode=l : key registration 

is performed using mode 1 

The CF does not define the meaning of modes 
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0 and 1. These modes are defined on the basis 
of the network key management architecture , 
and (as far as the CF is concerned) can be 
whatever a customer wants them to be. This 
parameter is required only when process- 
mode=(0 or 1) and key-management-protocol=l . 



I KU1- LENGTH 



The length of IKU1 in bytes. This parameter 
is required only when process-mode=(0 or 1) 
and dsigl-length > 0. 



IKU1 



An Internal Key Unit containing a PUM of 
another device and belonging to domain- id. 
The value of EID in SCB1 must not equal the 
value in the EID register. The values of 
Tstart and Texp in SCB1 must satisfy the 
relationship Tstart =< DT < Texp, where DT 
is the current date and time expressed in 
Coordinated Universal Time. This parameter 
is required only when process-mode=(0 or 1) 
and dsigl-length > 0. 



I KU2 -LENGTH 



The length of IKU2 in bytes. This parameter 
is required only when process-mode=(0 or 1). 



IKU2 An Internal Key Unit containing a PRM of 

this device and belonging to domain-id. The 
value of EID in SCB2 must equal the value in 
the EID register. The values of Tstart and 
Texp in SCB2 must satisfy the relationship 
Tstart < DT < Texp, where DT is the current 
date and time expressed in Coordinated 
Universal Time. This parameter is required 
only when process -mode=(0 or 1). 

KEYBLK-LENGTH The length of keyblk and ePUM(keyblk) in 
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bits. This parameter is required only when 
process-mode=(0 or 1). 



EPUM(KEYBLK) 



keyblk encrypted with public key PUM of this 
device. For process-mode=0, keyblk is a key 
block produced from a Crypto Facility DEA Key 
Record (CFDKR) . For process -mode={ 1 or 2), 
keyblk has an unspecified format. This para- 
meter is required only when process-mode=(0 
or 1). 



DSIG1 -LENGTH 



DSIG1 



The length of dsigl in bits. A value of 
dsigl-length=0 indicates that no dsigl 
parameter is specified to the IDK instruction. 
This parameter is required only when process- 
mode= (0 or 1 ) . 

A digital signature produced from a CF System 
Signature Record (CFSSR) and a private key 
management key PRM of another device , in 
accordance with section 6 of ISO DIS 9796. 
The CFSSR contains a 128-bit hash value 
calculated on ePUM( keyblk) . This parameter 
is required only when process-mode=(0 or 2) 
and dsigl-length > 0. 



TICKET- IN An 8-byte value that must be equal to the 

8-byte value stored in the IDK Ticket field 
in the CF Environment. This parameter is 
required only when process -mode=2 . 

SENDER-EID A 128-bit environment ID of the sender of 
the DEA key. This parameter is required 
only when process -mode=0 or process-mode=2 . 



C3 



A 16-byte control vector associated with 
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10 



KKL, where KKL is the leftmost 64 bits of 
the key-encrypting receiver key KK to be 
imported. For process-mode=0, C3 MUST be 
equal to the control vector stored in keyblk 
of input parameter ePUM(keyblk) . See 
control vector checking for a specification 
of C3. This parameter is required only when 
process-raode=(0 or 2). 



C4 



75 



20 



25 



OUTPUTS 



A 16-byte control vector associated with 
KKL, where KKL is the leftmost 64 bits of 
the key-encrypting receiver key KK to be 
imported. Except for certain fields which 
CFAP is permitted to set, C4 must equal C3. 
Control vector checking ensures that C4 is a 
valid derivative of C3. This parameter is 
required only when process-mode=( 0 or 2). 

DESCRIPTION 



E*KM.C5(KKL) 



30 



35 



40 



64 bit key KKL enciphered under 128 bit 
master key KM and 128 bit control vector C5. 
KKL is the left half of a 128 bit key-encrypt- 
ing key. Except for certain fields which the 
IDK instruction is permitted to set, C5 must 
equal C4 . C5 is derived from C4 via an 
internal control vector generation routine. 
This parameter is required only when process- 
mode= (0 or 2 ) . 



E*KM.C6 (KKR) 



64 bit key KKR enciphered under 128 bit 
master key KM and 128 bit control vector C6. 
KKR is the right half of a 128 bit key-encrypt- 
ing key. C6 is derived from C5 via an 
internal control vector generation routine. 



50 



55 
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This parameter is required only when process- 
mode= (0 or 2 ) . 

TICKET-OUT An 8-byte value equal to an 8-byte value 

stored in the IDK-Ticket register in the CF. 
This parameter is required only when 
process-mode=l . 

cc condition code indicating success or failure 

of the instruction execution. 



DESCRIPTION: 

The IDK Instruction reenciphers a 128-bit key-encrypting key KK { = KKL.KKR) in encrypted form ePUM- 
(keyblk) to encrypted form e'KM.CS(KKL), e*KM.C6(KKR). ePUM(keyblk) denotes a key block containing KK 
encrypted with a public key management key of this device. e*KM.C5(KKL) and e*KM.C6(KKR) are the 
encrypted left and right 64-bit parts of KK, respectively. KM.C5 and KM.C6 are variant keys formed as the 
Exclusive-OR product of master key KM and control vectors C5 and C6, respectively. C5 and C6 are control 
vectors associated with KKL and KKR, respectively. C5 and C6 designate KK as a key- encrypting receiver 
key with an "RTMK" attribute. The EXPORT CONTROL field in C5 and C6 must also specify 'no export.' 

A process-mode parameter provides different processing options within the IDK instruction. When 
process-mode = 0 is specified, keyblk is a key block produced from a Crypto Facility DEA Key Record 
(CFDKR). The format of the CFDKR and the algorithm for producing keyblk from CFDKR are rigidly defined 
by PKCD. Process-modes 1 and 2 permit a keyblk with unspecified format to be processed. This is 
accomplished by invoking the IDK instruction with processmode = 1 to decrypt ePUM(keyblk) and store the 
recovered keyblk within the CF, then invoking a Translate-TO-CFDKR instruction which translates the keyblk 
to a CFDKR also stored within the CF, and finally invoking the IDK instruction with process-mode = 2 to 
process and recover KK from the so-produced CFDKR and to produce e*KM.C5(KKL), e*KM.C6(KKR). The 
aim of process-modes 1 and 2 is to remove the translation step from the IDK instruction, so that the IDK 
instruction need not directly implement a host of different possible translation options for compatibility with 
other non-PKCD devices. A significant advantage can be achieved if the Translate-To-CFDKR instruction is 
implemented within a programmable memory within the CF. 

The dsigl -length parameter indicates to the IDK instruction whether ePUM(keyblk) has an accompany- 
ing system signature, dsigl (dsigl -length>0), or has no accompanying system signature (dsig1-length = 0). 
If present, dsigl is validated with a public key, PU, contained in the specified Internal Key Unit, IKU1. 
ePUM(keyblk) may be imported with no accompanying system signature. 

A field in the configuration vector, designated SIG-COMPATIBILITY(IDK), indicates whether dsigl is 
required (i.e., signified by SIG-COMPATIBILITY(IDK) = B'O') or whether dsigl is optional (i.e., signified by 
SIG-COMPATIBILITY(IDK) = B'V). For example, when dsigl -length = 0 is specified, the IDK instruction 
ensures that SIG-COMPATIBILITY(IDK) = BT. In other words, when a device is configured as a 
compatibility device, the IDK instruction does not require specification of a system signature. 

Control vectors C3, C4, and C5 are all associated with the KKL to be imported. C3 must be equal in 
value to the control vector stored in CFDKR. The EXPORT CONTROL field in C3, C4, and C5 must specify 
•no export/ C4 is an intermediate value used by the CFAP to request changes to C3, as follows. When a 
KKL is imported, the CFAP is permitted, in certain cases, to change control vector fields. If no change is 
desired or no change is permitted, then the CFAP sets C4 := C3, else the CFAP produces C4 by making 
selected changes to C3. The control vector checking process assures that C4 is properly specified. 
Likewise, when a KKL is imported the CF is permitted to change certain control vector fields. If no change is 
needed or prescribed, then the CF sets C5 : = C4; else the CF produces C5 by making selected changes to 
C4. Control vector C6 associated with KKR is derived within the Import DEA Key instruction from C5. 

The Import DEA Key instruction executes only in the "run" state. 
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FUNCTIONAL SPECIFICATION: 

1. Verify process-mode = 0, 1, or 2. If verification fails, set CC status flag and jump to step 17. 

2. Validate ticket-in, and extract fields from CF Environment, if process-mode = 2: 
5 If process-mode = 2 then do: 

a. Verify IDK Buffer Flag in CF Environment = 1 . If verification fails then set CC status flag and jump 
to step 17. 

b. Verify ticket-in : = value stored in IDK Ticket field in CF Environment. If verification fails then set 
CC status flag and jump to step 17. 

w c. Set domain-id : = bits 00..03 of IDK Save field in CF Environment. 

d. Set key-management-protocol : = bit 04 of IDK Save field in CF Environment. 

e. Set key-management-mode : = bit 05 of IDK Save field in CF Environment. 

f. Set cfdkrl-length := value stored in IDK Record Length field in CF Environment. 

g. Set cfdkrl := leftmost cfdkrl-length bits of value stored in IDK Buffer field in CF Environment. 
75 3. Perform input parameter consistency checking if process-mode = 0 or 1 : 

If process-mode = 0 or process-mode = 1 then do: 

a. If dsigl-length > 0, then verify that IKU1 is consistent to definition of an IKU. 

b. Verify that IKU2 is consistent to definition of an IKU. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 17. 
20 4. Perform configuration vector and state vector checking: 

a. Verify that DEFINE(IDK) in config. vector = B*1\ 

b. If key-management-protocol = 1, then KMGT PROTOCOL in config. vector = B'1V or B'10\ 

c. If key-management-protocol = 1 and key-management-mode = 0, then KREG in config. vector = 
B'0\ 

25 d. If key-management-protocol = 0, then KMGT PROTOCOL in config. vector = B'1V or B'01\ 

e. Verify that CF STATE in state vector is in the "run" state. 

f. Verify that KMP-FLAG(CKMP) in state vector is in the "full" state. 

g. Verify that CKM FLAG in state vector is in the "full" state. 

h. (optional) Verify LPID FLAG in state vector is in the "full" state. 
30 I Verify that ENABLE(IDK) in state vector = B'OO*. 

j. If process-mode = 0 or process-mode = 1, and if dsigl -length = 0, then verify SIG- 
COMPATIBILITY(IDK) in config. vector = BT. 
Continue if checking succeeds; otherwise set CC status flag and jump to step 17. 

5. Perform control block and control vector checking. 

35 Continue if checking succeeds; otherwise set CC status flag and jump to step 17. 

6. Construct expected record-code to be referenced against record-code stored in cfssrl, if (process- 
mode = 0 or process-mode = 1) and dsigl-length > 0: 

a. Extract control vector C from IKU1 

b. Construct record-code from control vector C. 

40 7. Recover and validate cfssrl, if (process-mode = 0 or process-mode = 1) and dsigl-length > 0: 

a. Recover cryptographic facility system signature record cfssrl from from digital signature dsigl, 
using the public key stored in IKU1. 

b. Verify that cfssrl is consistent to definition of a cryptographic facility system signature record. 

c. Extract hash rule hash-rulel from cfssrl . 

45 d. Verify that record-code stored in cfssrl is the same as record-code constructed in step 6. 

Continue if verifications succeed; otherwise set CC status flag and jump to step 17. 

8. Calculate hash value MDC on ePUM(keyblk) using the hash algorithm specified by hash-rulel, if 
(process-mode = 0 or process-mode = 1) and dsigl-length > 0. 

9. Validate MDC against reference MDC in cfssrl, if (process-mode = 0 or process-mode = 1) and 
50 dsigl-length > 0: 

a. Extract the hash value stored in the hash field in cfssrl. 

b. Verify that MDC is the same as the extracted hash value. 

Continue if verification succeeds; otherwise set CC status flag and jump to step 17. 

10. Recover cfdkrl if process-mode = 0: 
55 a. Set key-process : = 1 

b. Recover the CFDKR cfdkrl from the encrypted DEA key block ePUM(keyblk), using the private key 
PRM stored in IKU2. 

11. Recover key block, if process-mode = 1: 
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a. Set key-process : = 0 

b. Recover the key block keyblk from the encrypted DEA key block ePUM(keyblk), using the private 
key PRM stored in IKU2. 

12. Produce output ticket-out and store parameter values in CF Environment if process-mode = 1: 

a. Produce ticket-out: 

1) Generate an 8-byte random number and assign it to ticket-out. 

b. Save parameter values in CF Environment: 

1) Set IDK Ticket field in CF Environment : = ticket-out 

2) If key-process = 0, then set IDK Buffer Flag in CF Environment : = 2 

3) Else (key-process = 1) set IDK Buffer Flag in CF Environment : = 3 

4) Set IDK Save field in CF Environment := domain-id || key-management-protocol || key- 
management-mode jj B'OO' 

5) Set IDK Buffer field in CF Environment : = keyblk (left-justified in IDK Buffer field). 

6) Set IDK Record Length field in CF Environment := keyblk-length 

7) Set IDK Buffer Length field in CF Environment : = value of IDK-buffer-length in Configuration 
Table. 

13. Construct a record code record-codel for cfdkrl based on parameters key-management-protocol 
and key-management-mode, if process-mode = 0 or process-mode = 2. 

14. Validate cfdkrl if process-mode = 0 or process-mode = 2: 

a. Verify cfdkrl -length = 416 r check length 7. 

b. Verify that record ID in cfdkrl is B'00000000'. 

c. Extract the one-byte record code from cfdkrl and assign it to Y. 

d. Verify record-codel = (B'11111000 v AND Y) ("AND" is logical AND) 

e. Verify that the value of the EID field in cfdkrl is not the same as the contents of the EID register 
in CF Environment (i.e., EID acts as an anti-reimport value.) 

f. Verify that the value of the EID field in cfdkrl is the same as the sender-EID. r receiver can't be 
fooled about sender's identity 7 

g. Verify that the value of the hash control vector field (i.e.,h(C)) in cfdkrl is the same as C3. 

h. Extracted the 64-bit left half KKL of the 128-bit key KK from cfdkrl. 

i. Verify that parity of KKL is odd. 

j. Extracted the 64-bit right half KKR of the 128-bit key KK from cfdkrl. 
k. Verify that parity of KKR is odd. 
1 . Verify that reserved fields in cfdkrl are all zero. 
Continue if verifications succeed; otherwise set CC status flag and jump to step 17. 

15. Produce outputs e*KM.C5(KKL) and e*KM.C6(KKR) if process-mode = 0 or process-mode = 2: 

a. Set KM : = contents of CKM Register in the CF Environment. 

b. Set C5 : = C4 and update the history bits in C5 if necessary, 

c. Exclusive-OR KM with C5 and use the resulting key to to encrypt KKL. 

d. Set C6 : = C5 and invert the values in bits 41 and 42 in C5 (i.e., adjust the KEY FORM field in 
C5). 

e. Exclusive-OR KM with C6 and use the resulting key to to encrypt KKR. 

16. Perform state vector update: None. 

17. Produce output CC from CC status flags. 

CONTROL BLOCK AND CONTROL VECTOR CHECKING: 
Perform control block and control vector checking: 

A Perform the checking in steps 1 and 2, if process-mode = 0 or process-mode = 2: 
1 . Checking on C3 (associated with KKL): 

a. CV TYPE in C3 = "Key-Encrypting Receiver Key' b. Verify RTMK usage in C3 = B'V (i.e., 

enabled) 

c. Verify XLTKEY-in in C3 = B'O' (i.e., disabled) 

d. Verify GKS in C3 = B'000' (i.e., disabled) 

e. Verify EXPORT CONTROL in C3 = B'O* (i.e., export via RFMK not permitted) 

f. Verify KEY FORM = B'010' or B'110' (i.e., KKL) 

g. Verify EXTENSION in C3 = B'OO' or B'OT. 

h. If EXTENSION in C3 = B'OO', then do: 

1) Verify C3R = C3L (i.e., CV EXTENSION = CV BASE) 
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2) Verify domain-id (in instruction) = 0 
i. If EXTENSION in C3 = B'OT, then do: 

1) Verify DOMAIN ID in C3 = domain-id (in instruction). 

2) Verify HIST-GKSP/IDK field in C3 = BT 

2. Checking on C3 and C4: 
a. Verify C4 = C3. 

NOTE: Currently there is nothing in C3 that can be changed by CFAP in the IDK instruction. 
Continue if checking succeeds; otherwise set CC status flag and jump to step 17. 
B Perform the checking in steps 3 thru 9, if process-mode = 0 or process-mode = 1: 

3. Extract SCB1 and C1 from IKU1, if dsigl-length > 0: 

a. Extract system control block SCB1 from IKU1. 

b. Extract control vector C1 from SCB1. 

4. Extract SCB2 and C2 from IKU2: 

a. Extract system control block SCB2 from IKU2. 

b. Extract control vector C2 from SCB2. 

5. Checking on C1 (associated with PUM), if dsigl-length > 0: 

a. Verify CV TYPE in C1 = 'public key management key* 

b. Verify IDK in C1 = BT (i.e., enabled) 

c. Verify HIST-IPUK = BT (i.e., imported) 

d. Verify DOMAIN ID in C1 = domain-id (in instruction) 

e. If key-management-protocol (in instruction) = BT (i.e., 'certification center protocol'), then do: 

1) If key-management-mode (in instruction) = 0, then KREGMODE in C1 = B'OT. 

2) If key-management-mode (in instruction) = 1, then KREGMODE in CI = B'10'. 

3) Verify HIST-CHAIN in C1 = 2. 

f. Perform Control Vector Validate on CI to validate certain fields in C1 . 

6. Checking on C2 (associated with PRM): 

a. Verify CV TYPE in C2 = 'private key management key' 

b. Verify IDK usage in C2 = BT (i.e., enabled) 

c. Verify DOMAIN ID in C2 = domain-id (in instruction) 

d. Perform Control Vector Validate on C1 to validate certain fields in C2. 

7. Checking on C1 and C2 (associated with PUM and PRM), if dsigl-length > 0: 

a. Verify HIST-MDC in Ct > THRES-MDC in C2. (This check is valid for private protocols and 
certification center protocols.) 

8. Checking on SCB1, if dsigl-length > 0: 

a. Verify that the current date and time are in the time interval (Tstart.Texp), specified in SCB1 (i.e., 
Tstart =< DT < Texp). 

b. Verify that the Environment ID stored in the EID register is not the same as the Environment ID 
stored in SCB1 . 

9. Checking on SCB2: 

a. Verify that the current date and time are in the time interval (Tstart,Texp), specified in SCB2 (i.e., 
Tstart =< DT< Texp). 

b. Verify that the Environment ID stored in the EID register is the same as the Environment ID 
stored in SCB2. 

Continue if checking succeeds; otherwise set CC status flag and jump to step 17. 



Internal Key Unit (VIKU) 



EQUATION: 



KMP-mode 

IKUl-length 

IKU1 



/2b/ 
/16b/ 



/unspecified/ 



--> 



CC 



/unspecified/ 
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PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 



KMP-MODE 



Specifies the PKA master key as follows: 



10 



0 
1 
2 



CKMP 
NKMP 
OKMP 



75 



I KUl -LENGTH The length of IKU1 in bytes, 



IKU1 



An Internal Key Unit, 



20 



25 



OUTPUTS 



CC 



DESCRIPTION 

Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

30 The Verify Internal Key Unit instruction extracts the encrypted CFPKR and encrypted CFKAR from an 
Internal Key Unit, decrypts them, and validates the CFPKR using the CFKAR. A KMP-mode parameter 
permits the validation to be performed using the current, new, or old PKA master key. 
The Verify Internal Key Unit instruction executes only in the "run" state. 

35 SYSTEM DIGITAL SIGNATURES 



40 



45 



50 



Generate Digital Signature (GDS) 
PR-mode 
<IKUl-length> 
<IKU1> 
data- length 
data 

hash-rule 
inst-code 
— > 

dsig-length 

dsig 

CC 



/lb/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 

/3b/ 

/4b/ 

/16b/ 

/unspecified/ 
/unspecified/ 



if PR-mode=0 
if PR-mode=0 



55 



PARAMETER DEFINITIONS: 
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INPUTS 
PR-MODE 



DESCRIPTION 

The PR-mode parameter specifies the source 
of the private key used to generate the 
digital signature, as follows: 



o PR-mode=0 : use PR in IKU1 
o PR-mode=l : use PRA in CF 



IKU1-LENGTH 



IKU1 



The length of IKU1 in bytes. This parameter 
is required only when PR-mode=0. 

An Internal Key Unit containing a private 
key PR. PR must be a private certification 
key/ a private key management key, or a 
private user key. The value of EID in SCB1 
must equal the value in the EID register. 
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The values of Tstart and Texp in SCB1 must 
satisfy the relationship Tstart < DT < Texp, 
where DT is the current date and time ex- 
pressed in Coordinated Universal Time. This 
parameter is required only when PR-mode=0. 



DATA-LENGTH The length of data in bits, 



DATA 



HASH-RULE 



INST-CODE 



The data upon which a digital signature is 
to be calculated. 

Specifies the hash algorithm to be used to 
hash the input data and the rule, if any, 
for formatting and producing the CF System 
Signature Record (CFSSR) . The encoding of 
the hash-rule is as follows: 

o hash-rule = 0 : MDC-2 algorithm (with 

128 bit hash right justified in the Hash 
field) . 

o hash-rule = 1 : MDC-4 algorithm (with 

128 bit hash right justified in the Hash 
field) . 

o hash-rule = 2 : MD4 algorithm (with 128 
bit hash right justified in the Hash 
field) 

o hash-rule - 3 : quadratic residue (with 
128 bit hash right justified in the Hash 
field) 

o hash-rule = 4 - 15 : reserved 

Specifies the PKCD instruction to be emulated 
(inst-codes 0 thru 3) or the GDS instruction 
(inst-code=4), as follows: 



inst-code=0 : ECFAR instruction 
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o inst-code=l 

o inst-code=2 

o inst-code=3 

o inst-code=4 



EPUK instruction 
GKSP instruction 
ECFER instruction 
GDS instruction 



NOTE: For inst-code=0, data is a CFAR; for 
inst-code=l, data is an EKU; for inst- 
code=2, data is ePUM(keyblk) ; for inst- 
code=3, data is ePUA(CFBDKB) . 



OUTPUTS 
DSIG- LENGTH 
DSIG 



DESCRIPTION 

The length of dsig in bits. 

A digital signature produced from a CF 
System Signature Record (CFSSR) according to 
the signature generation processing rules 
outlined in Section 6 of ISO DIS 9796, 



CC 



Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Generate Digital Signature instruction generates a digital signature, called dsig, from a Crypto 
Facility System Signature Record (CFSSR) in accordance with Section 6 of ISO DIS 9796. The CFSSR is a 
253-bit CF-generated record containing a 128-bit hash value calculated on a variable length input data 
record, called data. The length of CFSSR must be less than or equal to 1/2 the modulus length of the public 
key algorithm. The process of producing dsig from CFSSR consists of pre-processing steps, decryption 
with a private key, and post-processing steps. 

A PR-mode parameter specifies to the GDS instruction whether the PR key used to produce the system 
signature is specified in IKU1 (PR-mode = 0) or whether the PR key used to produce the system signature is 
the PRA key stored in the CF (PR-mode = 1). 

A private certification key can be specified to the GDS instruction only when the device is configured as 
a certification center (CERTIFICATION field in the configuration vector is BT). A private authentication key, 
a private key management key, or a private user key can be specified to the GDS instruction only when the 
device is configured as an interchange device (INTERCHANGE field in the configuration vector is BT). A 
device may act as both a certification center and an interchange device. 

The GDS instruction executes only in the "run" state. 

Verify Digital Signature (YDS) 



135 



EP 0 534 419 A2 



PU-mode 
<IKUl-length> 
<IKU1> 
data- length 
data 

dsig-length 
dsig 

— > 

hash-rule 
inst-code 
CC 



/lb/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 

/4b/ 
/4b/ 

/unspecified/ 



; if PU-mode=0 
; if PU-mode=0 



PARAMETER DEFINITIONS: 



INPUTS 



DESCRIPTION 
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PU-MODE 



The PU-mode parameter specifies the source 
of the public key used to validate the 
digital signature, as follows: 



o PU-mode=0 : use PU in IKU1 
o PU-mode=l : use PUA in CF 



IKU1 -LENGTH 



IKU1 



DATA-LENGTH 
DATA 



The length of IKU1 in bytes. This parameter 
is required only when PU-mode=0. 

An Internal Key Unit containing a public key 
PU. The values of Tstart and Texp in SCB1 
must satisfy the relationship Tstart < DT < 
Texp, where DT is the current date and time 
expressed in Coordinated Universal Time. This 
parameter is required only when PU-mode=0. 

The length of data in bits. 

The data upon which a digital signature is 
to be calculated. 



DS I G -LENGTH 
DSIG 



The length of dsig in bits. 

A digital signature originally produced from 
a CF System Signature Record (CFSSR) according 
to the signature generation processing rules 
outlined in Section 6 of ISO DIS 9796. 



OUTPUTS DESCRIPTION 

HASH-RULE The encoded hash-rule field in the CF System 

Signature Record (CFSSR), as follows: 



o hash-rule = 0 : MDC-2 algorithm (with 128 
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bit hash right justified in the Hash field) . 
o hash-rule = 1 : MDC-4 algorithm (with 128 

bit hash right justified in the Hash field), 
o hash-rule = 2 : MD4 algorithm (with 128 

bit hash right justified in the Hash field) 
o hash-rule - 3 : quadratic residue (with 128 

bit hash right justified in the Hash field) 
o hash-rule = 4 - 15 : reserved 

INST-CODE The leftmost 4 bits of the Record Code field 

in the CF System Signature Record (CFSSR) 
(i.e., the PKCD instruction that created the 
digital signature or the PKCD instruction 
emulated by a GDS instruction), as follows: 



o 


inst- 


-code=0 


a 


ECFAR instruction 


o 


inst- 


-code=l 


• 


EPUK instruction 


o 


inst- 


-code =2 


• 
• 


GKSP instruction 


o 


inst- 


-code=3 


• 


ECFER instruction 


o 


inst- 


-code=4 




GDS instruction 



NOTE: For inst-code=0, data is a CFAR; for 
inst-code=l, data is an EKU; for inst-code=2, 
data is ePUM(keyblk) ; for inst-code=3, data 
is ePUA(CFBDKB) ♦ 

Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Verify Digital Signature instruction verifies a system signature, called dsig, in accordance with 
Section 7 of ISO DIS 9796, where dsig was created from a Crypto Facility System Signature Record 
(CFSSR) in accordance with Section 6 of ISO DIS 9796. The CFSSR is a 253-bit CF-generated record 
containing a 128-bit hash value calculated on a variable length input data record, called data. CFSSR is 
recovered from dsig by encrypting dsig with a public key, performing consistency checking on the 
recovered block, and discarding redundant data and extracting CFSSR. 

There are no restrictions on the key type of the public key that may be used with the VDS instruction. 

The VDS instruction executes only in the "run" state. 
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APPLICATION DIGITAL SIGNATURES 
Generate Application Digital Signature (GADS) 

5 EQUATION: 

IKUl-length 
IKU1 

hash-val-length 
hash-val 
--> 

dsig-length 
dsig 
CC 



w 



75 



/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/unspecified/ 



20 



PARAMETER DEFINITIONS: 
INPUTS 



DESCRIPTION 



25 



IKU1-LENGTH The length of IKU1 in bytes. 



IKU1 



30 



An Internal Key Unit containing a private 
key PR. PR must be a private certification 
key, a private key management key, or a 
private user key. The value of EID in SCB1 



35 



40 



45 



50 



55 
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must equal the value in the EID register. 
The values of Tstart and Texp in SCB1 must 
satisfy the relationship Tstart < DT < Texp, 
where DT is the current date and time 
expressed in Coordinated Universal Time. 

HASH-VAL-LENGTH The length of hash-val in bytes. It must be 
< one half of modulus length indicated in 
the control vector associated with the 
private key PR in IKU1. 

The hash value on which the signature is 
produced, hash-val is computed from the data 
by either the application or CFAP, using any 
hash algorithm. 

DESCRIPTION 



The length of dsig in bits. 

A digital signature produced from hash-val 
and private key PR in accordance with 
section 6 of ISO DIS 9796. 

Condition code indicating success or failure 
of the instruction execution. 



HASH-VAL 

OUTPUTS 
DSIG-LENGTH 
DSIG 

CC 



DESCRIPTION: 

The Generate Application Digital Signature instruction generates a digital signature, called dsig, from an 
input hash value (called hash-val) in accordance with Section 6 of ISO DIS 9796. hash-val must be a whole 
number of bytes and the length of hash-val must be less than or equal to 1/2 the modulus length of the 
public key algorithm. The process of producing dsig from hash-val consists of preprocessing steps, 
decryption with a private key, and post-processing steps. 

A signature produced by the GADS instruction is called an application signature; a signature produced 
by the ECFAR, EPUK, GKSP, ECFER, or GDS instruction is called a system signature. To prevent the 
GADS instruction from producing a system signature, the system signature is produced from a 253-bit CF 
System Signature Record, whereas the application signature is produced from a hash value consisting of a 
whole number of bytes. Note that 253 bits is not a whole number of bytes. 

A private certification key can be specified to the GADS instruction only if the device is configured as a 
certification center (CERTIFICATION field in the configuration vector is BT). 

The GADS instruction executes only in the "run" state. 
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Verify Application Digital Signature (VADS) 
EQUATION: 



70 



IKUl-length 
IKU1 

hash-val- length 
hash-val 
dsig-length 
dsig 

— > 

CC 



/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/unspecified/ 



PARAMETER DEFINITIONS: 
20 INPUTS DESCRIPTION 
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30 
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I Kill -LENGTH The length of IKU1 in bytes. 

IKU 1 An Internal Key Unit containing a public key 

PU. The values of Tstart and Texp in SCBl 
must satisfy the relationship Tstart < DT < 
Texp, where DT is the current date and time 
expressed in Coordinated Universal Time. 

HASH-VAL-LENGTH The length of hash-val in bytes. It must be 
< one half of modulus length indicated in 
the control vector associated with the 
public key PU in IKU1. 



HASH-VAL 



The hash value on which the signature is 
produced, hash-val is computed from the data 
by either the application or CFAP, using any 
hash algorithm. 



DSIG-LENGTH 
DSIG 



The length of dsig in bits. 

A digital signature produced from hash-val 
and private key PR in accordance with 
section 6 of ISO DIS 9796, and which is 
validated in the VADS instruction using the 
public key PU (specified in IKUl) in accord- 
ance with section 7 of ISO DIS 9796. 



OUTPUTS 



CC 



DESCRIPTION 

Condition code indicating success or failure 
of the instruction execution. 



DESCRIPTION: 

The Verify Application Digital Signature instruction validates a digital signature, called dsig, using an 
input hash value (called hash-val) and a public key PU in accordance with Section 7 of ISO DIS 9796. hash- 
val must be a whole number of bytes and the length of hash-val must be less than or equal to 1/2 the 
modulus length of the public key algorithm. The process of validating dsig consists of encryption with a 
public key, consistency checking to validate the redundancy bytes, and recovery of of the hash-value-of- 
reference originally used to generate dsig. The hash value supplied to the VADS instruction (i.e., hash-val) 
is compared for equality with hash-value-of-reference. 
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A signature validated by the VADS instruction is called an application signature; a signature validated by 
the VDS instruction is called a system signature. See the GADS instruction for an explanation of system and 
application signatures. 

The VADS instruction operates with any public key supplied in IKU1. 

The VADS instruction executes only in the "run" state. 

CF BACKUP 

Export Crypto Facility Environment Record (ECFER) 



70 



75 



20 



25 



30 



EQUATION: 



protocol-mode 

KM-mode 

KMP-mode 

hash-rule 

IKUl-length 

IKU1 

— > 

xcfer-length 
xcfer 

cfbdkbl-length 

ePUAb(cfbdkbl) 

dsigl-length 

dslgl 

CC 



/2b minimum/ 
/lb minimum/ 
/lb minimum/ 
/3b minimum/ 
/16b/ 

/unspecified/ 
/32b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/unspecified/ 



35 



PARAMETER DEFINITIONS: 
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45 



50 
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INPUTS DESCRIPTION 

PROTOCOL-MODE The protocol-mode parameter specifies the 
protocol used for export and import of the 
CF environment, as follows: 



o 0 : reserved 

o 1 : CBKUP1 (certification center protocol 

where the PUA control vector has 

HIST-CHAIN=2) 
o 2 : CBKUP2 (certification center protocol 

where the PUA control vector has 

HIST-CHAIN=3) 
o 3 : PBKUP (private protocol, i.e., no 

restriction on how PUA is imported) 



Note that the control vector for PUAb (i.e., 
CI) contains a similar BKUP PROTOCOL field 
that must match the protocol-mode parameter. 

KM-MODE The KM-mode parameter indicates whether the 

master key KM is required to be entered into 
the new KM register at the receiving device 
via the LFMKP and CMKP instructions: 
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o KM-mode=0 : no 

o KM-mode=l : yes (load via LFMKP and CMKP) 

NOTE: KM-mode=l should be selected only if 
the value of KM is known outside the crypto 
facility, i.e., KM was originally loaded 
into the CF of the sending device via the 
LFMKP and CMKP instructions. 

KMP-MODE The KMP-mode parameter indicates whether the 

PKA master key KMP is required to be entered 
into the new KMP register at the receiving 
device via the LFPMKP and CPMKP instructions: 

o KMP-mode = 0 : no 

o KMP-mode = 1 : yes (load via LFPMKP and * 
CPMKP) 

NOTE: KMP-mode=l should be selected only if 
the value of KMP is known outside the crypto 
facility, i.e., KMP was originally loaded 
into the CF of the sending device via the 
LFPMKP and CPMKP instructions. 

HASH-RULE Specifies the hash algorithm to be used to 

calculate a hash value on ePUAb(cfbdkbl) and 
on the cfer. The encoding of the hash-rule 
is as follows: 

o hash-rule = 0 : MDC-2 algorithm 
o hash-rule = 1 : MDC-4 algorithm 
o hash-rule = 2 : MD4 algorithm 
o hash-rule = 3 : quadratic residue 
o hash-rule = 4-7 : reserved 

I KU1- LENGTH The length of IKU1 in bytes. 
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IKU1 



An internal Key Unit containing PUAb of 
device "b". Note that "a" is this device 
and "b" is the other device. The value of 
EID in SCB1 must not equal the value in the 
EID register. The values of Tstart and Texp 
in SCB1 must satisfy the relationship Tstart 
< DT < Texp, where DT is the current date and 
time expressed in Coordinated Universal Time. 



OUTPUTS 



DESCRIPTION 



XCFER-LENGTH The length of xcfer in bytes, 



XCFER 



An External Crypto Facility Environment 
Record . 



CFBDKB 1 -LENGTH The length of cfbdkbl and ePUAb(cfbdkbl) in 
bits. 

EPUAB ( CFBDKB 1 ) cfbdkbl encrypted with public key PUAb of 

device "b". The Encrypted Secret Part (ESP) 
in xcfer is encrypted with a key stored in 
cfbdkbl. cfbdkbl also contains a 128-bit 
hash value (MDC) calculated on cfer. 



DSIGl -LENGTH 
DSIG1 



CC 



The length of dsigl in bits. 

A digital signature produced from a CF 
System Signature Record (CFSSR) and a 
private authentication key PRAa of device 
"a", in accordance with section 6 of ISO DIS 
9796. The CFSSR contains a 128-bit hash 
value calculated on ePUAb ( cfbdkbl ) . 

Condition code indicating success or failure 



of the instruction execution. 
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DESCRIPTION: 

The Export Crypto Facility Environment Record instruction constructs an External Crypto Facility 
Environment Record, xcfer, an encrypted Crypto Facility Backup Key Block, ePUAb(cfbdkbl), and a digital 

5 signature, dsigl. dsigl is calculated from a Crypto Facility System Signature Record (cfssrl) and a private 
authentication key PRAa. Subscripts "a" and "b" designate this device and another device, respectively, 
cfssrl contains a hash value (e.g., an MDC) calculated on ePUAb(cfbdkbl), i.e., the digital signature 
authenticates ePUAb(cfbdkbl). cfbdkbl contains a similar hash value (e.g., an MDC) calculated on cfer, 
which permits xcfer to be authenticated. Both hash values (i.e., the hash value in cfssrl and the hash value 

to in cfbdkbl) are calculated using the same hash algorithm, as specified in the hash-rule parameter of the 
ECFER instruction, cfbdkbl also contains a 128 bit key KK2 used to encrypt the Secret Part (SP) of xcfer, 
where KK2 = KK1 xor X xor Y. xcfer also contains a Nonsecret Part (NSP). The values X and Y are 
determined as follows: (1) X : = KMP if KMP-mode = 1 and X := 0 if KMP = mode = 0, and (2) Y := KM if 
KM-mode = 1 and Y := 0 if KM-mode = 0. Together SP and NSP constitute everything in the CF 

75 Environment except the PUA and PRA key, their length fields, and control vectors, and the contents of the 
DID register. These elements do not port in the xcfer. 

Any one of three protocol modes may be used to export and import a CF-environment record: (a) 
PBKUP, (b) CBKUP1, and (c) CBKUP2. The PBKUP (i.e., private protocol) mode is the least restrictive. This 
mode permits an installation to effect device backup using privately exchanged PUA keys. The CBKUP1 

20 and CBKUP2 modes make use of a certification center to indirectly validate the PUA key, and thus are 
more restrictive. In the CBKUP2 mode, the control vector of the PUA key must have a HIST-CHAIN value 
equal to 3, i.e., the PUA key is imported using a PUM key whose control vector has a HIST-CHAIN value 
equal to 2 and the PUM key is imported using a PUC key whose control vector has a HIST-CHAIN value 
equal 1. In the CBKUP1 mode, the control vector of the PUA key must have a HIST-CHAIN value equal to 

25 2, i.e., the PUA key is imported using a PUC key whose control vector has a HIST-CHAIN value equal to 1. 
Several mechanisms are provided to authorize and control the execution of the ECFER instruction. 
These control mechanisms are effected via the configuration vector, the control vectors, and the instruction 
parameters. The ECFER and ICFER instructions are designed to operate only if both the exporting and 
importing devices "agree" to use the same protocol and protocol options. In effect, this means that both 

30 devices must be configured the same (i.e., both configuration vectors must be the same with respect to 
device backup), both devices must use the same key management protocol, and the same parameter 
options must be specified to the ECFER and ICFER instructions. The following addition conditions are 
enforced: (1) the method of loading or generating KMP at the exporting and importing devices must be the 
same, and (2) when protocol-mode = 1 or 2 the PUC keys (or PUM and PUC keys) used at the exporting 

35 and importing devices to import the PUA keys must be the same. A HIST-DOMAIN ID field in the state 
vector of a cloned CF environment records the domain identifier of the PUC keys (or PUC and PUM keys) 
used to import the PUA keys when protocol modes 1 or 2 are used. By using the ECFAR instruction, a 
cloned device can be audited to ensure that backup and recovery was effected with the proper PUC key. 
Agreement between the exporting and importing devices is effected through the use of the record code field 

40 in the Crypto Facility Backup DEA Key Record and through direct comparisons of the information stored in 
the CFER produced at the exporting device and the CF Environment of the importing device. 

The ECFER and ICFER instructions provide an option requiring the master key KM and/or the PKA 
master key KMP to be reentered at the importing (or receiving) device. In that case, the cryptovariable 
encrypting key KK1 under which the Secret Part of xcfer is encrypted can be recovered at the receiving 

45 device only if the required values of KM and/or KMP have been properly entered. This option permits a CF 
Environment to be ported without exposing KM or KMP to any greater extent than would otherwise be 
required for ordinary manual key entry at a sending or receiving device. 
The ECFER instruction executes only in the "run" state. 

50 Import Crypto Facility Environment Record (ICFER) 

EQUATION: 

PARAMETER DEFINITIONS: 

55 
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protocol-mode 

KM-mode 

KMP-mode 

IKUl-length 

IKU1 

xcfer-length 
xcfer 

cfbdkbl-length 
ePUAb(cfbdkbl) 
dsigl-length 
dsigl 

--> 

cc 



/2b minimum/ 
/lb minimum/ 
/lb minimum/ 
/16b/ 

/unspecified/ 
/32b/ 

/unspecified/ 
/16b/ 

/unspecified/ 
/16b/ 

/unspecified/ 



/unspecified/ 



DEFINITIONS: 
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INPUTS 



DESCRIPTION 



PROTOCOL-MODE The protocol-mode parameter specifies the 
protocol used for export and import of the 
CF environment , as follows: 



0 
1 



o 2 



o 3 



: reserved 

: CBKUP1 (certification center protocol 
where the PUA control vector has HIST- 
CHAIN=2 ) 

: CBKUP2 (certification center protocol 
where the PUA control vector has 
HIST-CHAIN=3) 

: PBKUP (private protocol, i.e., no 
restriction on how PUA is imported) 



KM-MODE 



Note that the control vector for PUAa (i.e., 
CI) contains a similar BKUP PROTOCOL field 
that must match the protocol-mode parameter. 

The KM-mode parameter indicates whether the 
master key KM is required to be entered into 
the new KM register at the receiving device 
via the LFMKP and CMKP instructions: 



o KM-mode =0 : no 

o KM-mode=l : yes (load via LFMKP and CMKP) 



NOTE: KM-mode=l should be selected only if 
the value of KM is known outside the crypto 
facility, i.e., KM was originally loaded 
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into the CF of the sending device via the 
LFMKP and CMKP instructions. 

KMP-MODE The KMP-mode parameter indicates whether the 

PKA master key KMP is required to be entered 
into the new KMP register at the receiving 
device via the LFPMKP and CPMKP instructions: 

o KMP-mode = 0 : no 

o KMP-mode = 1 : yes (load via LFPMKP and 
CPMKP) 

NOTE: KMP-mode=l should be selected only if 
the value of KMP is known outside the crypto 
facility, i.e., KMP was originally loaded 
into the CF of the sending device via the 
LFPMKP and CPMKP instructions. 



I KU1 -LENGTH The length of IKU1 in bytes. 



IKU1 An internal Key Unit containing PUAa of de- 

vice "a". Note that "a" is the other device 
and "b" is this device. The value of EID in 
SCBl must not equal the value in the EID 
register. The values of Tstart and Texp in 
SCBl must satisfy the relationship Tstart < 
DT < Texp, where DT is the current date and 
time expressed in Coordinated Universal Time. 



XCFER-LENGTH The length of xcfer in bytes. 

XCFER An External Crypto Facility Environment 

Record . 

CFBDKB1 -LENGTH The length of cfbdkbl and ePUAb(cfbdkbl) in 
bits. 
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EPUAB(CFBDKBl) cfbdkbl encrypted with public key PUAb of 

device "b" . The Encrypted Secret Part (ESP) 
in xcfer is encrypted with a key stored in 
cfbdkbl. cfbdkbl also contains a 128-bit 
hash value (MDC) calculated on cfer. 



w DSIG1 -LENGTH The length of dsigl in bits. 



DSIG1 A digital signature produced from a CF 

System Signature Record (CFSSR) and a 
private authentication key PRAa of device 
"a", in accordance with section 6 of ISO DIS 
9796. The CFSSR contains a 128-bit hash 
20 value calculated on ePUAb ( cfbdkbl ) . 



OUTPUTS DESCRIPTION 

CC Condition code indicating success or failure 

of the instruction execution. 



30 



DESCRIPTION: 



The Import Crypto Facility Environment Record instruction permits an xcfer produced with an ECFER 
35 instruction, at a sending device, to be imported at a receiving device. In effect, the output of an ECFER 
instruction becomes the Input to an ICFER instruction. Execution of the ICFER instruction causes the 
variables stored in the xcfer to replace the comparable variables in the CF Environment of the receiving 
device. 

The inputs to the Import Crypto Facility Environment Record instruction consists of an External Crypto 

40 Facility Environment Record, xcfer, an encrypted Crypto Facility Backup Key Block, ePUAb(cfbdkbl), and a 
digital signature, dsigl. dsigl is calculated from a Crypto Facility System Signature Record (cfssrl) and a 
private authentication key PRAa. Subscripts "b w and "a" designate this device and another device, 
respectively, cfssrl contains a hash value (e.g., an MDC) calculated on ePUAb(cfbdkb1 ), i.e., the digital 
signature authenticates ePUAb(cfbdkbt). cfbdkbl contains a similar hash value (e.g., an MDC) calculated on 

45 cfer, which permits xcfer to be authenticated: Both hash values (i.e., the hash value in cfssrl and the hash 
value in cfbdkbl) are calculated using the same hash algorithm, as originally specified in the hash-rule 
parameter of the ECFER instruction, cfbdkbl also contains a 128 bit key KK2 used to encrypt the Secret 
Part (SP) of xcfer, where KK2 = KK1 xor X xor Y. xcfer also contains a Nonsecret Part (NSP). The values X 
and Y are determined as follows: (1) X := KMP if KMP-mode = 1 and X := 0 if KMP = mode=0, and (2) Y 

50 := KM if KM-mode = 1 and Y := 0 if KM-mode = 0. Together SP and NSP constitute everything in the CF 
Environment except the PUA and PRA key, their length fields, and control vectors, and the contents of the 
DID register. These elements do not port in the xcfer. 

Any one of three protocol modes may be used to export and import a CF-environment record: (a) 
PBKUP. (b) CBKUP1, and (c) CBKUP2. The PBKUP (i.e., private protocol) mode is the least restrictive. This 

55 mode permits an installation to effect device backup using privately exchanged PUA keys. The CBKUP1 
and CBKUP2 modes make use of a certification center to indirectly validate the PUA key, and thus are 
more restrictive. In the CBKUP2 mode, the control vector of the PUA key must have a HIST-CHAIN value 
equal to .3, i.e., the PUA key is imported using a PUM key whose control vector has a HIST-CHAIN value 
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70 



15 



20 



25 



30 



equal to 2 and the PUM key is imported using a PUC key whose control vector has a HIST-CHAIN value 
equal to 1. In the CBKUP1 mode, the control vector of the PUA key must have a HIST-CHAIN value equal 
to 2, i.e., the PUA key is imported using a PUC key whose control vector has a HIST-CHAIN value equal to 

Several mechanisms are provided to authorize and control the execution of the ICFER instruction. 
These control mechanisms are effected via the configuration vector, the control vectors, and the instruction 
parameters. The ECFER and ICFER instructions are designed to operate only if both the exporting and 
importing devices "agree" to use the same protocol and protocol options. In effect, this means that both 
devices must be configured the same (i.e., both configuration vectors must be the same with respect to 
device backup), both devices must use the same key management protocol, and the same parameter 
options must be specified to the ECFER and ICFER instructions. The following addition conditions are 
enforced: (1) the method of loading or generating KMP at the exporting and importing devices must be the 
same, and (2) when protocol-mode = 1 or 2 the PUC keys (or PUM and PUC keys) used at the exporting 
and importing devices to import the PUA keys must be the same. A HIST-DOMAIN ID field in the state 
vector of a cloned CF environment records the domain identifier of the PUC keys (or PUC and PUM keys) 
used to import the PUA keys when protocol modes 1 or 2 are used. By using the EC FAR instruction, a 
cloned device can be audited to ensure that backup and recovery was effected with the proper PUC key. 
Agreement between the exporting and importing devices is effected through the use of the record code field 
in the Crypto Facility Backup DEA Key Record and through direct comparisons of the information stored in 
the CFER produced at the exporting device and the CF Environment of the importing device. 

The ECFER and ICFER instructions provide an option requiring the master key KM and/or the PKA 
master key KMP to be reentered at the importing (or receiving) device. In that case, the cryptovariable 
encrypting key KK1 under which the Secret Part of xcfer is encrypted can be recovered at the receiving 
device only if the required values of KM and/or KMP have been properly entered. This option permits a CF 
Environment to be ported without exposing KM or KMP to any greater extent than would otherwise be 
required for ordinary manual key entry at a sending or receiving device. To permit recovery, KMP must be 
reentered into the NKMP register and KM must be reentered into the NKM register using the CF 
instructions. The concept of CF Environment backup using the ECFER and ICFER instructions is such that 
the PUA and PRA keys are not ported from one device to another. Thus, when a CF Environment is 
reimported at a receiving device, the existing PUA and PRA keys are not changed, and the content of the 
DID register is not changed. However, the content of the EID register IS changed, i.e., the content of the 
EID register ports from one device to another. These ensure that existing certificates containing EID remain 
valid, and the anti-reimport property of EID remains valid. 

The ICFER instruction executes only in the "run" state. 



35 



40 



45 



50 



55 



Set and Reset Alarm (SRALM) 

EQUATION: 



mode /lb minimum/ 

— > 

CC /unspecified/ 



PARAMETER DEFINITIONS: 

INPUTS DESCRIPTION 
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MODE 



A parameter indicating whether to set or 
reset alarm, as follows: 



0 : reset alarm 



w 



15 



OUTPUTS 
CC 



o 1 : set alarm 
DESCRIPTION 

Condition code indicating success or failure 
of the instruction execution. 



20 DESCRIPTION: 

The Set and Reset Alarm instruction signals the CF that an "alarm" condition should be set or reset. 
The term "alarm" means a signal sent on a line, e.g., causing a light to come on or a signal to be sent on a 
monitoring line to a central location. 
25 Besides the frequently used Key Record Encrypt and Key Record Decrypt algorithms, there are other 
algorithms commonly used by the PKCD instructions. They are described as follows. 

IPRN - Initialize Pseudo-Random Number Algorithm 

30 Inputs: None. 
Outputs: None. 

Algorithm Description: 

35 1. Produce KK1 and KK2 from PRNGKEY1, PRNGKEY2 and PRNGCTR1 registers: 

a. Set KK1L : = leftmost PRNGKEY1 XOR PRNGCTR1 

b. Set KK1R : = rightmost PRNGKEY1 XOR PRNGCTR1 

c. Set KK2L : = leftmost PRNGKEY2 XOR PRNGCTR1 

d. Set KK2R : = rightmost PRNGKEY2 XOR PRNGCTR1 

40 NOTE: : the IPRN algorithm assumes that PRNGCTR1 is continuously updated by by hardware. If 
PRNGCTR1 is not implemented, one may alternatively read an internal Time of Day clock value and, if 
TOD has more than 64 bits, use the low-order 64 bits of TOD instead of PRNGCTR1. 

2. Calculate KK3 and KK4: 

a. Calculate a hash value on KK1 using the MDC-2 algorithm, and assign the result to KK3. 
45 b. Calculate a hash value on KK2 using the MDC-2 algorithm, and assign the result to KK4. 

Note this step eliminates the need to erase or zeroize the PRNGKEY1 and PRNGKEY2 registers when 
the CF Environment is clear. It also distributes any randomness uniformly over the key. 

3. Fix bite in KK3 and KK4: 

a. Set bits 00..01 of KK3 : = BW. 
50 b. Set bits 64..65 of KK3 : = B'01 \ 

c. Set bits 00..01 of KK4 := B'10\ 

d. Set bits 64..6S of KK4 : = B'1 1 \ 

4. (Optional) adjust parity of KK3 and KK4: 

a. For each byte in KK3 and KK4 (whose bits are numbered bO to b7), set bit b7 so that bits bO thru 
55 b7 have an odd number of bits set to B , V. 

5. Write KK3 to PRNGKEY1 register and KK4 to PRNGKEY2 register: 
a. PRNGKEY1 := KK3. b. PRNGKEY2 := KK4. 
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ENCKU - Encrypt CKU to IKU Algorithm 

The ENCKU algorithm is the inverse of the RCKUI algorithm. 
The ENCKU algorithm is as follows: 
ENCKU(KMP,N1,CKU -■> IKU) 
Inputs: 

KMP A 128 bit DEA key. 
N1 The length of CKU and IKU in bytes. 
CKU A Clear Key Unit. 
Outputs: 

IKU An Internal Key Unit. 
Algorithm Description: 

1. Extract control data (consisting of a system control block concatenated to a user control block) from 
CKU. 

2. Extract key record and key authenticator record from CKU. 

3. Encrypt key record and key authenticator record using the method described in the Key Record 
Encrypt algorithm. 

4. Convert CKU to IKU by updating the header and by replacing the key record and key authenticator 
record in CKU with encrypted key record and encrypted key authenticator, respectively. 

RCKUI - Recover CKU from IKU Algorithm 

The RCKUI algorithm is the inverse of the ENCKU algorithm. 
The RCKUI algorithm is as follows: 
RCKUI(KMP,N1,IKU -> CKU.RC) 
Inputs: 

KMP A 128 bit DEA key. 
N1 The length of IKU in bytes. 
IKU An Internal Key Unit. 
Outputs: 

CKU A Clear Key Unit. 
RC Return code 

1 . successful completion 

2. key authenticator record in the IKU does not verify 
Algorithm Description: 

1. Extract the control data from IKU. 

2. Extract encrypted key record and encrypted key authenticator record from CKU. 

3. Decrypt encrypted key record and encrypted key authenticator record using the method described in 
the Key Record Decrypt algorithm. 

4. Convert IKU to CKU by updating the header and by replacing the encrypted key record and encrypted 
key authenticator record in IKU with key record and key authenticator, respectively. 

PKGA - PKA Key Generation Algorithm 

The PKA Key Generation algorithm is as follows: 
PKGA(C,GMODE,CODEWORD t RES -> S1,CFPKR1,S2,CFPKR2,RC) 
Inputs: 

c A 16 byte control vector of the generated public key. 

GMODE A parameter indicating the mode of key generation, as follows: 

'R* : Random - Key generation makes use of an L-bit seed randomly generated. 

■D' : Derived - Key generation makes use of an L-bit seed derived from a 128 bit 

codeword supplied as an input parameter. 
CODEWORD A 128 bit "seed" value used to generate an L-bit pseudorandom number. 
RES A parameter indicating key length restrictions, as follows: 
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o 0 : no restriction 



o 1 : length restriction type "1 " 



5 



S1 

CFPKR1 
S2 

CFPKR2 
RC 



Outputs: 

The length of cfpkrl in 8-byte blocks. 

A Crypto Facility PKA Key Record containing a generated public key. 
The length of cfpkr2 in 8-byte blocks. 

A Crypto Facility PKA Key Record containing a generated private key. 
Return code 



1. - successful operation 



70 



2. - Algorithm specified in the control vector is not supported 



Algorithm Description: 

1. Set alg := ALGORITHM field in C 
75 2. If gmode^R', then generate an L-bit seed using a random or a pseudorandom number generator. 

3. Else (gmode = 'D'), derive an L-bit seed from the supplied codeword. 

4. Perform the Key Generation Algorithm (KGA) on the L-bit seed to generate a pair of public and private 
key records cfpkrl and cfpkr2, respectively. 

NOTE: KGA and the method for deriving an L-bit seed from a codeword have been described in co- 
20 pending patent by S.M. Matyas, et al. entitled "Generating Public and Private Key Pairs using a 
Passphrase," cited in the background art. 

CWLD - Control Vector Validate Algorithm 

25 The Control Vector Validate algorithm is as follows: 
CWLD(CI -> RC) 
Inputs: 

CI The input control vector Ci on which the CV checking is performed. 
Outputs: 

30 RC Return code 



Algorithm Description: 

35 

The Control Vector Validate checks a control vector associated with a PKA key. No checking is 
performed on the CV TYPE field. 
I.Set RC : = 0 

2. Verify ANTIVARIANT ZERO in Ci = B'0' 
40 3. Verify ANTIVARIANT ONE in Ci = B'V 

4. Verify EXTENSION in Ci = BMO' (i.e., >128 bit control vector) 

5. Verify TESTZERO in Ci = B'OOO* (i.e., RPZ are valid) 

6. If checking fails, then set RC : = 1 and abort operation. 

45 CVG - Control Vector Generation Algorithm 

The Control Vector Generate algorithm is used by the IPUK instruction to set history information in an 
output control vector. The specific fields set by the Control Vector Generate routine are HIST-IPUK, HIST- 
CHAIN, HIST-MDC, HIST-DOMAIN ID and HIST-KREGMODE. These history fields are interrogated for 
so compliance with minimum threshold values set forth in the configuration vector and in other control vectors, 
when a public key is used for key management or CF environment backup 

The Control Vector Generate is as follows: 



1. successful completion 

2. unsuccessful completion 



55 
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CVG(IMP0RT-M0DE,MDC-M0DE,MDC-INDEX,S1GNATURE-M0DE,C1,C2 -> C3) 



Inputs: 



10 



15 



20 



IMPORT-MODE 



MDC-MODE 



MDC-INDEX 



SIGNATURE-MODE 



C1 

C2 



C3 



A 1 bit value indicating the import-mode, as follows: 

o 0 : import-mode = 0 in IPUK instruction 

o 1 : import-mode = 1 in IPUK instruction 
A 1 bit value indicating the MDC-mode, as follows: 

o 0 : MDC-mode = 0 in IPUK instruction 

o 1 : MDC-mode = 1 in IPUK instruction 
This parameter is valid only when import-mode = 0. 
A parameter has a value equal to the MDC-index parameter in the IPUK 
instruction. 

A 2 bit value indicating the signature mode, as follows: 

o 0 : signature-mode = 0 in IPUK instruction 

o 1 : signature-mode = 1 in IPUK instruction 

o 2 : signature-mode = 2 in IPUK instruction 
A 16 byte control vector associated with a PU to be imported. 
A 16 byte control vector associated with a PU used to validate a digital 
signature. 
Outputs: 

A 16 byte control vector, associated with the imported PU. 



Algorithm Description: 

25 

1. SetC3 := C1 

2. Update HIST-IPUK field: 

a. Set HIST-IPUK in C3 := BT (i.e., imported) 

3. Update HIST-MDC field: 

30 a. If import-mode = 0 and mdc-mode = 0, then set HIST-MDC in C3 := B'OT. 

b. If import-mode =0 and mdc-mode = 1, then set HIST-MDC in C3 := EKUMDC FLAG(mdc-index) in 
state vector. 

c. If import-mode = 1, then set HIST-MDC in C3 := HIST-MDC in C2. 

4. Update HIST-KREGMODE field, if CV TYPE in C1 = 'PUA' and CV TYPE in C2 = 'PUM': 

35 a. Set HIST-KREGMODE in C3 : = KREGMODE in C2. Note: The HIST-KREGMODE field may contain 

valid history information when HIST-CHAIN * B'11\ Notwithstanding this, the HIST-KREGMODE field 
is considered valid only when HIST-IPUK = BT and HIST-CHAIN = B'11. 

NOTE: Since for import-mode = 0 CV TYPE in C1 always equals CV TYPE in C2, step 4 is executed only 

when import-mode = 1 . 

40 5. Update HIST-DOMAIN ID field, if CV TYPE in C1 = 'PUA' and (CV TYPE in C2 = 'PUC or CV TYPE 
in C2 = 'PUM): 

a. Set HIST-DOMAIN ID in C3 : = DOMAIN ID in C2. Note: The HIST-DOMAIN ID field may contain 
valid history information when HIST-CHAIN * B'KT or B'11\ Notwithstanding this, the HIST-DOMAIN 
ID field is considered valid only when HIST-IPUK = BT and (either HIST-CHAIN = B'10 or HIST- 
45 CHAIN = B'11'). 

NOTE: Since for import-mode = 0 CV TYPE in C1 always equals CV TYPE in C2, step 5 is executed only 

when import-mode - 1 . 

6. Update HIST-CHAIN field: 

a. Set HIST-CHAIN in C3 : = BW 
50 b. If (import-mode = 0) and (signature-mode = 0 or signature-mode = 1 ) and (CV TYPE in C1 = 'PUC 1 ), 

then set HIST-CHAIN in C3 := BW. 

c. If (import-mode = 1) and (CV TYPE in C1 = TUC) and (CV TYPE in C2 = 'PUC') and (HIST-IPUK 
in C2 = BT) and (HIST-CHAIN in C2 = B'OT) and (DOMAIN ID in C1 = DOMAIN ID in C2), then set 
HIST-CHAIN inC3:= B'OT. 
55 d. If (import-mode = 1) and (CV TYPE in C1 = 'PUM') and (CV TYPE in C2 = 'PUC') and (HIST-IPUK 

in C2 = BT) and (HIST-CHAIN in C2 = B*01') and (DOMAIN ID in C1 = DOMAIN ID in C2), then set 
HIST-CHAIN inC3:= BM0\ 
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e. If (import-mode = 1) and (CV TYPE in C1 = *PUA*) and (CV TYPE in C2 = TUC) and (HIST-IPUK 
in C2 = BT) and (HIST-CHAIN in C2 = B'OV), then set HIST-CHAIN in C3 := B'10\ 

f. If (import-mode = 1) and (CV TYPE in C1 = *PUA') and (HIST-IPUK in C1 = B'O') and (CV TYPE in 
C2 = 'PUIvV) and (HIST-IPUK in C2 = B'V) and (HIST-CHAIN in C2 = BMO'), then set HIST-CHAIN 

5 in C3 := B'1 V. Note: Checking that HIST-IPUK in C1 = B'O* ensures that PUA is generated at the 

same device as the PRM used to generate the digital signature on EKU. 
NOTE: For import-mode = 0 and signature-mode = 0, HIST-CHAIN is set equal to B'00\ which, in terms of 
the CFAP definition of •merit 1 , limits all imported PU keys to be 'BRONZE* keys (i.e., no 'GOLD' or 
'SILVER* keys can be imported). 
10 Although a specific embodiment of the invention has been disclosed, it will be understood by those 
having skill in the art that changes can be made to the specific embodiment without departing from the 
spirit and the scope of the invention. 

Claims 

15 

1. In a data processing system, a method for managing a public key cryptographic system, comprising 
the steps of: 

generating a first public key and a first private key as a first pair in said data processing system, for 
20 use with a first public key algorithm; 

generating a second public key and a second private key as a second pair in said data processing 
system, for use with a second public key algorithm; 

25 assigning a private control vector for said first private key and said second private key in said data 
processing system, for defining permitted uses for said first and second private keys; 

forming a private key record which includes said first private key and said second private key in said 
data processing system, and encrypting said private key record under a first master key expression 
30 which is a function of said private control vector; 

forming a private key token which includes said private control vector and said private key record, and 
storing said private key token in said data processing system; 

35 receiving a first key use request in said data processing system, requiring said first public key 
algorithm; 

accessing said private key token in said data processing system and checking said private control 
vector to determine if said private key record contains a key having permitted uses which will satisfy 
40 said first request; 

decrypting said private key record under said first master key expression in said data processing 
system and extracting said first private key from said private key record; 

45 selecting said first public key algorithm in said data processing system for said first key use request; 

executing said first public key algorithm in said data processing system using said first private key to 
perform a cryptographic operation to satisfy said first key use request. 

so 2. The method of claim 1 , which further comprises: 

said private key record including first parse data to locate said first private key and said second private 
key in said key record; 

55 said extracting step including using said parse data for extracting said first private key from said private 
key record. 
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3. The method of claim 1 or 2, which further comprises: 

forming a first private key authentication record in said data processing system, by computing a hash 
value using a hashing function on said private key record and encrypting said first private key 
5 authentication record under a second master key expression which is a function of said private control 
vector; 

said private key token including said first private key authentication record. 
w 4. The method of claim 3, which further comprises: 

after said decrypting step, computing a second private key authentication record in said data 
processing system, by computing a second hash value using said hashing function on said decrypted 
private key record and comparing said second a private key authentication record with said first private 
75 key authentication record; 

aborting further processing of said first key use request in said data processing system, if said second 
private key authentication record is not equal to said first private key authentication record. 

20 5. The method of claim 4, which further comprises: 

said private key token including first header data to locate said control vector, said private key record 
and said private key authentication record in said private key token; 

25 said accessing step including using said header data to locate said private key record in said private 
key token. 

6. The method of claim 1 or anyone of the claims 2 to 5, which further comprises: 

so assigning a public control vector for said first public key and said second public key in said data 
processing system, for defining permitted uses for said first and second public keys; 

forming a public key record which includes said first public key and said second public key in said data 
processing system, and encrypting said public key record under a third master key expression which is 
35 a function of said public control vector; 

forming a public key token which includes said public control vector and said public key record, and 
storing said public key token in said data processing system; 

40 receiving a second key use request in said data processing system, requiring said second public key 
algorithm; 

accessing said public key token in said data processing system and checking said public control vector 
to determine if said public key record contains a key having permitted uses which will satisfy said 
45 second request; 

decrypting said public key record under said third master key expression in said data processing 
system and extracting said first public key from said public key record; 

so selecting said second public key algorithm in said data processing system for said second key use 
request; 

executing said second public key algorithm in said data processing system using said first public key 
to perform a cryptographic operation to satisfy said second key use request. 

The method of claim 6, which further comprises: 

said public key record including second parse data to locate said first public key and said second 
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public key in said key record; 

said extracting step for said first public key including using said parse data for extracting said first 
public key from said public key record. 

5 

8. The method of claim 6 or 7, which further comprises: 

forming a second public key authentication record in said data processing system, by computing a 
hash value using said hashing function on said public key record and encrypting said second public 
w key authentication record under a fourth master key expression which is a function of said public 
control vector; 

said public key token including said second public key authentication record. 

75 9. The method of claim 8, which further comprises: 

after said decrypting step for said public key record, computing a second public key authentication 
record in said data processing system, by computing a second hash value using said hashing function 
on said decrypted public key record and comparing said second a public key authentication record with 
20 said second public key authentication record; 

aborting further processing of said second key use request in said data processing system, if said 
second public key authentication record is not equal to said second public key authentication record. 

25 10. The method of claim 9, which further comprises: 

said public key token including second header data to locate said control vector, said public key record 
and said public key authentication record in said public key token; 

30 said accessing step for said public key token including using said header data to locate said public key 
record in said public key token. 

11. In a data processing system, a method for managing a public key cryptographic system, comprising 
the steps of: 

35 

generating a public key and a private key as a pair in said data processing system, for use with a 
public key algorithm; 

assigning a private control vector for said private key in said data processing system, for defining 
40 permitted uses for said private key; 

forming a private key record which includes said private key in said data processing system, and 
encrypting said private key record under a first master key expression which is a function of said 
private control vector; 

45 

forming a private key token which includes said private control vector and said encrypted private key 
record and storing said private key token in said data processing system; 

receiving a first key use request in said data processing system, requiring execution of said public key 
so algorithm with a private key; 

accessing said private key token in said data processing system and checking said private control 
vector to determine if said private key record contains a key having permitted uses which will satisfy 
said first request; 

55 

decrypting said private key record under said first master key expression in said data processing 
system and extracting said private key from said private key record; 
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executing said public key algorithm in said data processing system using said private key to perform a 
cryptographic operation to satisfy said first key use request. 

12. The method of claim 11, which further comprises: 

assigning a public control vector for said public key in said data processing system, for defining 
permitted uses for said public key; 

forming a public key record which includes said public key in said data processing system, and 
encrypting said public key record under a second master key expression which is a function of said 
public control vector; 

forming a public key token which includes said public control vector and said public key record and 
storing said public key token in said data processing system; 

receiving a second key use request in said data processing system, requiring execution of said public 
key algorithm with a public key; 

accessing said public key token in said data processing system and checking said public control vector 
to determine if said public key record contains a key having permitted uses which will satisfy said 
second request; 

decrypting said public key record under said second master key expression in said data processing 
system and extracting said public key from said public key record; 

executing said public key algorithm in said data processing system using said public key to perform a 
cryptographic operation to satisfy said second key use request. 

1a The method of claim 11 or 12, which further comprises: 

forming a first private key authentication record in said data processing system, by computing a hash 
value using a hashing function on said private key record; 

said private key token including said first private key authentication record. 

14. The method of claim 13, which further comprises: 

after said decryption step for said private key record, computing a second private key authentication 
record in said data processing system, by computing a second hash value using said hashing function 
on said decrypted private key record and comparing said second a private key authentication record 
with said first private key authentication record; 

aborting further processing of said first key use request in said data processing system, if said second 
private key authentication record is not equal to said first private key authentication record. 

15. The method of claim 14, which further comprises: 

forming a second public key authentication record in said data processing system, by computing a 
hash value using said hashing function on said public key record; 

said public key token including said second public key authentication record. 

16. The method of claim 15, which further comprises: 

after said decrypting step for said public key record, computing a second public key authentication 
record in said data processing system, by computing a second hash value using said hashing function 
on said decrypted public key record and comparing said second a public key authentication record with 
said second public key authentication record; 
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aborting further processing of said second key use request in said data processing system, if said 
second public key authentication record is not equal to said second public key authentication record. 

17. In a data processing system, a method for managing a public key cryptographic system, comprising 
the steps of: 

generating a public key and a private key in said cryptographic system; 

assigning a public key control vector to said public key in accordance with intended uses for said 
public key; 

assigning a private key control vector to said private key in accordance with intended uses for said 
private key; 

storing said public key in a public key record and storing said private key in a private key record; 

encrypting said public key record under a master key and encrypting said private key under said 
master key; 

forming a modification detection code on a concatenated expression of said public key control vector 
and said public key record as a public key authentication record; 

forming a modification detection code on a concatenated expression of said private control vector and 
said private key record to produce a private key authentication record; 

encrypting said public key authentication record under said master key and encrypting said private key 
authentication record under said master key; 

forming a public key token which includes said public key control vector in a first field, said encrypted 
public key record in a second field, and said encrypted public key authentication record in a third field; 

forming a private key token including said private key control vector in a first field, said encrypted 
private key record in a second field, and said encrypted private key authentication record in a third 
field. 

18. The method of claim 17 wherein said master key is a secret key, preferably a data encryption algorithm 
key belonging to a symmetric key algorithm. 

19. In a data processing system, a computer program for managing a public key cryptographic system, 
which when executed on said data processing system, performs a method comprising the steps of: 

generating a first public key and a first private key as a first pair in said data processing system, for 
use with a first public key algorithm; 

generating a second public key and a second private key as a second pair in said data processing 
system, for use with a second public key algorithm; 

assigning a private control vector for said first private key and said second private key in said data 
processing system, for defining permitted uses for said first and second private keys; 

forming a private key record which includes said first private key and said second private key in said 
data processing system, and encrypting said private key record under a first master key expression 
which is a function of said private control vector; 

forming a private key token which includes said private control vector and said private key record, and 
storing said private key token in said data processing system; 
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receiving a first key use request in said data processing system, requiring said first public key 
algorithm; 

accessing said private key token in said data processing system and checking said private control 
vector to determine if said private key record contains a key having permitted uses which will satisfy 
said first request; 

decrypting said private key record under said first master key expression in said data processing 
system and extracting said first private key from said private key record; 

selecting said first public key algorithm in said data processing system for said first key use request; 

executing said first public key algorithm in said data processing system using said first private key to 
perform a cryptographic operation to satisfy said first key use request. 

20. The computer program of claim 19, which further comprises: 

said private key record including first parse data to locate said first private key and said second private 
key in said key record; 

said extracting step including using said parse data for extracting said first private key from said private 
key record. 

21. The computer program of claim 19 or 20, which when executed on said data processing system, 
performs the further steps, comprising: 

forming a first private key authentication record in said data processing system, by computing a hash 
value using a hashing function on said private key record and encrypting said first private key 
authentication record under a second master key expression which is a function of said private control 
vector; 

said private key token including said first private key authentication record. 

22. The computer program of claim 21, which when executed on said data processing system, performs 
the further steps, comprising: 

after said decrypting step, computing a second private key authentication record in said data 
processing system, by computing a second hash value using said hashing function on said decrypted 
private key record and comparing said second a private key authentication record with said first private 
key authentication record; 

aborting further processing of said first key use request in said data processing system, if said second 
private key authentication record is not equal to said first private key authentication record. 

23. The computer program of claim 22, which further comprises: 

said private key token including first header data to locate said control vector, said private key record 
and said private key authentication record in said private key token; 

said accessing step including using said header data to locate said private key record in said private 
key token. 

24. In a data processing system, a computer program for managing a public key cryptographic system, 
which when executed on said data processing system, performs a method comprising the steps of: 

generating a public key and a private key as a pair in said data processing system, for use with a 
public key algorithm; 
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assigning a private control vector for said private key in said data processing system, for defining 
permitted uses for said private key; 

forming a private key record which includes said private key in said data processing system, and 
5 encrypting said private key record under a first master key expression which is a function of said 
private control vector; 

forming a private key token which includes said private control vector and said encrypted private key 
record and storing said private key token in said data processing system; 

70 

receiving a first key use request in said data processing system, requiring execution of said public key 
algorithm with a private key; 

accessing said private key token in said data processing system and checking said private control 
75 vector to determine if said private key record contains a key having permitted uses which will satisfy 
said first request; 

decrypting said private key record under said first master key expression in said data processing 
system and extracting said private key from said private key record; 

20 

executing said public key algorithm in said data processing system using said private key to perform a 
cryptographic operation to satisfy said first key use request. 

25. The computer program of claim 24, which when executed on said data processing system, performs 
25 the further steps, comprising: 

assigning a public control vector for said public key in said data processing system, for defining 
permitted uses for said public key; 

30 forming a public key record which includes said public key in said data processing system, and 
encrypting said public key record under a second master key expression which is a function of said 
public control vector; 

forming a public key token which includes said public control vector and said public key record and 
35 storing said public key token in said data processing system; 

receiving a second key use request in said data processing system, requiring execution of said public 
key algorithm with a public key; 

40 accessing said public key token in said data processing system and checking said public control vector 
to determine if said public key record contains a key having permitted uses which will satisfy said 
second request; 

decrypting said public key record under said second master key expression in said data processing 
45 system and extracting said public key from said public key record; 

executing said public key algorithm in said data processing system using said public key to perform a 
cryptographic operation to satisfy said second key use request. 

so 26. The computer program of claim 24 or 25, which when executed on said data processing system, 
performs the further steps, comprising: 

forming a first private key authentication record in said data processing system, by computing a hash 
value using a hashing function on said private key record; 

55 

said private key token including said first private key authentication record. 
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27. The computer program of claim 26. which when executed on said data processing system, performs 
the further steps, comprising: 

after said decryption step for said private key record, computing a second private key authentication 
record in said data processing system, by computing a second hash value using said hashing function 
on said decrypted private key record and comparing said second a private key authent.cat.on record 
with said first private key authentication record; 

aborting further processing of said first key use request in said data processing system, if said second 
private key authentication record is not equal to said first private key authentication record. 

2a The computer program of claim 27, which when executed on said data processing system, performs 
the further steps, comprising: 

forming a second public key authentication record in said data processing system, by computing a 
hash value using said hashing function on said public key record; 

said public key token including said second public key authentication record. 

29. The computer program of claim 28, which when executed on said data processing system, performs 
the further steps, comprising: 

after said decrypting step for said public key record, computing a second public key authentication 
record in said data processing system, by computing a second hash value using said hash.ng function 
on said decrypted public key record and comparing said second a public key authentication record with 
said second public key authentication record; 

aborting further processing of said second key use request in said data processing system, if said 
second public key authentication record is not equal to said second public key authent.cat.on record. 

30. A data processing system for managing a public key cryptographic system, comprising: 

first generating means for generating a first public key and a first private key as a first pair in said data 
processing system, for use with a first public key algorithm; 

second generating means for generating a second public key and a second private key as a second 
pair in said data processing system, for use with a second public key algorithm; 

assigning means for assigning a private control vector for said first private key and said second private 
key in said data processing system, for defining permitted uses for said first and second pnvate keys; 

key record forming means coupled to said first and second generating means, for forming a private key 
record which includes said first private key and said second private key in said data processing 
system encrypting means coupled to said key record forming means and said assigning means, for 
encrypting said private key record under a first master key expression which is a function of said 
private control vector; 

key token forming means coupled to said assigning means and to said key record forming means, for 
forming a private key token which includes said private control vector and said private key record; 

storing means coupled to said key token forming means, for storing said private key token in said data 
processing system; 

receiving means coupled to a user input, for receiving a first key use request in said data processing 
system, requiring said first public key algorithm; 

accessing means coupled to said receiving means and to said storing means, for accessing said 
private key token in said data processing system and checking said private control vector to determ.ne 



164 



EP 0 534 419 A2 



if said private key record contains a key having permitted uses which will satisfy said first request; 

decrypting means coupled to said accessing means, for decrypting said private key record under said 
first master key expression in said data processing system and extracting said first private key from 
5 said private key record; 

selecting means coupled to said receiving means, for selecting said first public key algorithm in said 
data processing system for said first key use request; 

io execution means coupled to said selecting means and to said decrypting means, for executing said first 
public key algorithm in said data processing system using said first private key to perform a 
cryptographic operation to satisfy said first key use request. 

31. The system of claim 30, which further comprises: 

15 

authentication record forming means coupled to said key record forming means, for forming a first 
private key authentication record in said data processing system, by computing a hash value using a 
hashing function on said private key record and encrypting said first private key authentication record 
under a second master key expression which is a function of said private control vector; 

20 

said private key token including said first private key authentication record. 

32. The system of claim 30 or 31 , which further comprises: 

25 computing means coupled to said decryption means, for computing a second private key authentication 
record in said data processing system, by computing a second hash value using said hashing function 
on said decrypted private key record and comparing said second a private key authentication record 
with said first private key authentication record; 

30 terminating means coupled to said computing means, for aborting further processing of said first key 
use request in said data processing system, if said second private key authentication record is not 
equal to said first private key authentication record. 
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